Re: pthread - system() blocking
Re: pthread - system() blocking
- Subject: Re: pthread - system() blocking
- From: Tilghman Lesher <email@hidden>
- Date: Tue, 01 Mar 2011 02:52:37 -0600
- Reply-by: Wed, 19 Jan 2011 16:20:00 -0600
On Tuesday 01 March 2011 02:09:18 Jean-Daniel Dupas wrote:
> Le 1 mars 2011 à 00:29, Jason Coco a écrit :
> > On Feb 28, 2011, at 18:20 , Stephen J. Butler wrote:
> >> On Mon, Feb 28, 2011 at 5:13 PM, Mark E. Armstrong
> >>
> >> <email@hidden> wrote:
> >>> In a pthread application, I need to call system() to execute an
> >>> external program. When system() is called in a non-main thread,
> >>> any other calls to system() are blocked until the previous call has
> >>> returned. How do we work around the blocking?
> >>
> >> Are you sure you aren't just seeing the effects of output buffering?
> >> That would be my first guess at what's happening... not that system()
> >> is being serialized.
> >>
> >> But if that IS actually the case, you can always fork/exec yourself.
> >
> > The system() call definitely blocks and is definitely serial. It will
> > also override your signal handling for SIGINT, SIGQUIT and SIGCHLD.
> > It's really just a simple convenience call for doing very simple
> > shell execs. If you want to run things in parallel, you'll have to
> > fork/exec
>
> Actually, the recommended way is to spawn a process (using posix_spawn)
> instead of using fork/exec yourself.
I think that would actually be race condition prone, because in a threaded
application, many calls for opening file descriptors do not support setting
the FD_CLOEXEC flag in the initial system call. Since a second system call
is needed to add the flag, there's an inherent race between those two
separate calls and a call to posix_spawn. This is only a problem, of
course, in multi-threaded applications.
Secondary to that is the issue of whether the process being spawned is a
short-lived process; if it is, it may be acceptable for some file
descriptors to remain open in the new process. However, a long-lived
process could certainly prevent a particular closure of, for example, a
pipe from sending the expected signal to the remote end.
I'd stick with the fork/exec, so you can deal with these issues directly.
--
Tilghman
_______________________________________________
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