Re: pthread - system() blocking
Re: pthread - system() blocking
- Subject: Re: pthread - system() blocking
- From: Greg Parker <email@hidden>
- Date: Tue, 1 Mar 2011 02:17:50 -0800
On Mar 1, 2011, at 1:54 AM, Chris Suter wrote: On Tue, Mar 1, 2011 at 8:47 PM, Greg Parker < email@hidden> wrote: No.
The problem is that there's no "close all but these" file action for
posix_spawn(). There's no safe way for posix_spawn() to create a child
process with all descriptors closed except a known set like stdin/out/err.
You cannot safely use posix_spawn_file_actions_addclose() for every open
descriptor in the parent, because other threads in the parent may be
concurrently opening and closing those descriptors between the time you set
up the file actions and the time you call posix_spawn().
But what if you added a close action for all possible file descriptors except for stdin, stdout & stderr? i.e. looped over all 1024 (or however many) file descriptors except for those three?
Doesn't work. If another thread is concurrently opening or closing descriptors during your scan and your call to posix_spawn(), you'll fail. 1. If you set posix_spawn_file_actions_addclose() for a descriptor, and another thread closes that descriptor before you call posix_spawn(), then posix_spawn() will return EBADF and not spawn the process. 2. If you fail to set posix_spawn_file_actions_addclose() for a descriptor, and another thread opens that descriptor before you call posix_spawn(), then the child process will have an unexpectedly open descriptor. This can lead to deadlocks elsewhere.
And how exactly would you close file descriptors between the fork and
exec? How do you know what file descriptors to close?
Just like you said above: you loop through all 1024 (or however many) file descriptors and close everything except the ones you want. This is safe in the fork/exec case because there's only one thread in the child after fork(), so there's no race with other manipulation of the child's descriptors.
--
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden