Multithreaded qsort(3)

Giorgos Keramidas keramida at
Mon Mar 19 21:05:55 UTC 2007

On 2007-03-18 15:25, Dan Nelson <dnelson at> wrote:
>In the last episode (Mar 18), Giorgos Keramidas said:
>>On 2007-03-17 23:43, Kip Macy <kip.macy at> 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 :)
> Btw - the Solaris 10 system manpage only mentions signal interactions
> as the cause for MT-unsafeness:
>     "The system() function manipulates the signal handlers for SIGINT,
>      SIGQUIT, and SIGCHLD.  It is therefore not safe to call system()
>      in a multithreaded process, since some other thread that
>      manipulates these signal handlers and a thread that concurrently
>      calls system() can interfere with each other in a destructive
>      manner.  If, however, no such other thread is active, system() can
>      safely be called concurrently from multiple threads.  See
>      popen(3C) for an alternative to system() that is thread-safe."
> It looks like there were some vfork-related system() bugs in older
> versions of Solaris, but they appear to have been fixed:

Thanks!  The bug description was a very good read.  The interaction with
the runtime linker didn't occur to me, but now I see :)

More information about the freebsd-threads mailing list