Multithreaded qsort(3)
Giorgos Keramidas
keramida at ceid.upatras.gr
Mon Mar 19 21:05:55 UTC 2007
On 2007-03-18 15:25, Dan Nelson <dnelson at allantgroup.com> wrote:
>In the last episode (Mar 18), Giorgos Keramidas said:
>>On 2007-03-17 23:43, Kip Macy <kip.macy at 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 :)
>
> 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:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4332595
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-arch
mailing list