site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meg.abyt.es; s=google; h=domainkey-signature:from:to:subject:date:user-agent:references :in-reply-to:reply-by:x-message:mime-version:content-type :content-transfer-encoding:message-id; bh=bhSZbhgAHYxw0DwecIbzmEgt1JKKS1AvCgcJ11AJSA0=; b=Kc9E6ls7yy7MPVwbDnBOLSl8QLhX1i2mI6Zzqyieal5M3pnhTCS0AHWFQwS0e/q/wq WBT8dUYPJT9+X3Emp2SNZffqet411CsvlFW6aRRnJhihnzNanra6BUYzwUMCKHoIUYAy wA9/nB2na0mSAVs7y8gl+sEq/k0yeLhrfFqOc= Domainkey-signature: a=rsa-sha1; c=nofws; d=meg.abyt.es; s=google; h=from:to:subject:date:user-agent:references:in-reply-to:reply-by :x-message:mime-version:content-type:content-transfer-encoding :message-id; b=X6OaV7VdXrMGt3sn1jh1juzE/ZoYAqQTHp5cDKHTBkGspEjqUmHT0LfVmEhCm7p/TH k/jZsLI+kayBLLIwaEP4QeazX6fj9q6XBOIEuAiDUoFWmNtwLeXnvww5iOq43YqNNofF UzvcdSyvzp7maLscMJeWnedu7SO6kg69QR1UI= Reply-by: Wed, 19 Jan 2011 16:20:00 -0600 User-agent: KMail/1.13.5 (Linux/2.6.32-29-server; KDE/4.4.5; x86_64; ; ) 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
<Mark.Armstrong@soleratec.com> 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com