Date: Sat, 17 Mar 2007 23:43:34 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "John-Mark Gurney" <gurney_j@resnet.uoregon.edu>, "Max Laier" <max@love2party.net>, freebsd-arch@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Multithreaded qsort(3) Message-ID: <b1fa29170703172343u2e54722cjfaf52ec7d4aed1c@mail.gmail.com> In-Reply-To: <20070318053307.GC73385@funkthat.com> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net> <20070318053307.GC73385@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/17/07, John-Mark Gurney <gurney_j@resnet.uoregon.edu> wrote:
> Max Laier wrote this message on Thu, Mar 15, 2007 at 18:27 +0100:
> > I'd suggest to name it qsort() and put it in a separate library (not
> > necessarily named libc_mt, as I don't believe there are that many
> > functions in libc, that can actually gain from multithreading).
>
> What happens when you attempt to link a library that uses qsort, but
> isn't multi-thread safe? You may be able to protect calls to the
> library w/ a lock, but then when it calls qsort, the library would
> break..
>
> Keeping the qsort name sounds ripe for problems down the road...
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).
-Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170703172343u2e54722cjfaf52ec7d4aed1c>