Comment 52 for bug 102408

(In reply to comment #31)
> Unfortunately in NSPR the same path is used to spawn an unrelated process
> and to fork your own process. If you explicitly close all the FDs when NSPR
> forks, half the unit tests fail.

I didn't understand how this applied to a default close-on-exec approach.
Sure this would be a problem if explicitly closing all FDs in the sense of
choice (2) of comment #41.

But for a default close-on-exec approach, PR_SetFDInheritable would be needed
on any FD needed across exec. (They would still be available after fork
but:)

Should an NSPR process wanting to fork use PR_CreateProcess to exec another
instance of itself? And is that what Mozilla does?
http://developer.mozilla.org/en/docs/Process_Forking_in_NSPR

I guess PR_SetFDInheritable would be needed in quite a few places then.
And if it can't be done after fork, that could get complicated.