User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20061206 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061206 Firefox/220.127.116.11 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.
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
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.