348399 - There is no way to get a PRProcess* from an existing PID

Status: RESOLVED WONTFIX

(NSPR :: NSPR, enhancement)

Description

[Julien Pierre]

NSPR offers some useful portable functions for process manipulation, such as PR_WaitProcess and PR_KillProcess . These functions require a PRProcess* . This is a platform-specific, opaque structure.

The only way to currently obtain one of those structures is to create the process from PR_CreateProcess, that is, from the parent process that created the child.

In some cases, process manipulation is needed from another process than the immediate parent. I'm proposing a new function :

PRProcess* PR_GetProcessFromPID(PRUint64 pid);

I believe PRUint64 should be large enough to handle the size of a PID on all our currently supported platforms.

Comment 1

[Julien Pierre]

I took a quick stab at fixing this on Solaris. I was able to make PR_KillProcess work on non-child processes, but I can't get PR_WaitProcess to work because the waitpid system call it relies on only operates on child processes.

Comment 2

[Julien Pierre]

Attachment: Work in progress

This is a patch that attempts to implement the RFE for Unix pthread platforms, including a test program. Unfortunately, it fails because there is no way to wait for uan unrelated process.

Comment 3

[Wan-Teh Chang]

Marked the bug WONTFIX.  It's not easy to design a
cross-platform process management API for two reasons.
1. On Unix the SIGCHLD signal is only sent to the parent
process, and only the parent process can call one of the
wait* functions to reap the terminated child process.
2. It's inappropriate for NSPR (a library) to own the
SIGCHILD signal handler, which is process-wide.

This is why I stopped further development of the PRProcess
API in NSPR.  NSPR-based applications may write platform
specific code to create and manage processes.