Status

--
enhancement
12 years ago
11 years ago

People

(Reporter: danny_milo, Assigned: wtc)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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.
(Assignee)

Comment 1

12 years ago
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?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

12 years ago
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)
(Reporter)

Comment 3

12 years ago
any news?

Comment 4

11 years ago
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.
You need to log in before you can comment on or make changes to this bug.