Date: Sun, 18 Mar 2007 15:49:01 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Kip Macy <kip.macy@gmail.com> Cc: Max Laier <max@love2party.net>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) Message-ID: <20070318134900.GA98260@kobe.laptop> In-Reply-To: <b1fa29170703172343u2e54722cjfaf52ec7d4aed1c@mail.gmail.com> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net> <20070318053307.GC73385@funkthat.com> <b1fa29170703172343u2e54722cjfaf52ec7d4aed1c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-03-17 23:43, Kip Macy <kip.macy@gmail.com> wrote: > Reminds me of how Solaris blindly uses vfork for implementing > system(3). It was very easy for a naive user (me) to call system from > a multi-threaded python application. I had numerous failures that were > impossible to track back to system(3). It seems like an 'obvious' optimization, though. vfork() will block the parent process until the child runs exec(), and the whole purpose of system is to exec() a shell and run an external command. Can you elaborate on the problems you were seeing? It sounds like something both interesting and educational :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070318134900.GA98260>