364582 - process observer missing

Status: NEW

(NSPR :: NSPR, enhancement)

Description

[Danny Milosavljevic]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9

Hi,

Reading 
http://www.mozilla.org/projects/nspr/reference/html/prprocess.html
I see the following is possible:
- create process
- wait synchronously until process is done (signaled)
- detaching process so it will be auto-reaped and not become a zombie

But there is no function that allows "waiting" *asynchronous* until a process is done (signaled), although on UNIX that seems like the obvious thing to do: 
start some tool, connect some observer that will be notified when tool is done. In the observer, do something else (upload, whatever).

Reproducible: Always

Steps to Reproduce:
1. CreateProcess
2. Want to get notified when process terminated
3. bummer


Expected Results:  
1. CreateProcess
2. Call function get notified when process terminated, like
  PR_SetProcessStateCallback(void (*callback)(NSProcess, pid, exit_code_if_any, signal_number))

Currently I'm working around that by using a native UNIX component that just uses fork()/exec()/waitpid(), completely bypassing NSPR. Obviously it would be nicer if NSPR itself either supported said behaviour or alternatively at least enable such a thing to be added without introducing funny process management races.

Comment 1

[Wan-Teh Chang]

Thank you for the suggestion.

I stopped adding new functions to the PRProcess API because
their implementation on Unix often requires a signal handler
for the SIGCHLD signal, and in some situations it is impossible
for NSPR to own the SIGCHLD handler for the process.  (A signal
handler is a process property.)

It seems that the feature you suggested would require an NSPR
internal thread to call the process-state callback function,
because Unix has serious restrictions on the functions you can
call from a signal handler.  You can only call the so-called
async-signal-safe functions from a signal handler.  Almost all
of the async-signal-safe functions are system calls.  So the
SIGCHLD signal handler would need to arrange for some other
internal thread to call the process-state callback function.

In your implementation, are you using a thread to call the
process-state callback functions?

Comment 2

[Danny Milosavljevic]

Hi,

> It seems that the feature you suggested would require an NSPR internal thread 

like in WaitPidDaemonThread when it is reaping the process

> to call the process-state callback function,
> because Unix has serious restrictions on the functions you can call from a signal handler.  

For example glib avoids that issue by adding an event to the event queue (which is thread safe, adding to a in-memory locked list, via g_idle_add). 
As mozilla is event based as well, I don't see an obvious problem with that (although NSPR would need to have _access_ to the event queue, which it probably doesn't have yet)

> You can only call the so-called async-signal-safe functions from a signal handler.  

Well, I don't care about *really really immediate* notification of a child termination. Queueing it as an event and having mozilla process it when it's bored is OK.

> Almost all of the async-signal-safe functions are system calls.
> So the SIGCHLD signal handler would need to arrange for some other internal thread to call the process-state callback function.

I guess that would work, too.

> In your implementation, are you using a thread to call the process-state callback functions?

In my implemenation, I poll waitpid() every few seconds (yeah yeah, bad me :)), from javascript, no less :)

But as I said, the nicest way I can see would to get an "some process terminated" event into the mainloop event queue and be over with...

(Note that I have only a passing understanding of mozilla and nspr overall architecture)

Comment 3

[Danny Milosavljevic]

any news?

Comment 4

[hippytrail]

I also need this functionality for an extension which launches bzip2 to decompress very large archives of wikipedia database dumps. I need notification when it is finished so I can go on to the next step.

Another approach would be if there was a way to get a handle to the underlying OS specific process so I could at least poll to see if it still exists. The pid returned by nsIProcess.run() seems to be of no use on Win32.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.