On Thu, Nov 03, 2016 at 08:24:55PM +0000, Emil Velikov wrote:
> Hi all,
>
> A recent change (commit fa6db2f9c01 - list.m4: Add some new pthread symbols)
> lead to an interesting bugreport [1] which makes me think that the current
> pthread-stubs design isn't as robust (broken?) as one would expect.
>
> In brief: if there is a pthread-stubs library, one can end up using a
> mismatched API - if one uses dlopen with a binary which pulls a full pthreads
> implementation. That is because the weak symbols, as provided by the
> pthread-stubs DSO, get overridden.
>
> This has gone unnoticed because a) on most platforms pthread-stubs never
> creates a DSO and in the rare case where it does b) it's very uncommon to
> dlopen a binary which pulls a non-lightweight pthreads symbols, from a
> pthreads-stubs (linked) one.
>
>
> The only solutions that I can think of are:
> 1) make pthread-stubs "meta package" who's Cflags/Libs expand to the platform
> specific PTHREAD_{CFLAGS,LIBS} if the runtime does not provide lightweight
> pthread symbols, or
> 2) "kill off" pthread-stubs and let everyone
> - handle the "do I need to link against pthreads or not" in their
> configure.ac
> - link against the complete/full pthread API
>
> Imho 2) is rather selfish/overzealous so I've went ahead and tackled 1).
The pthread stubs on most platforms exist to make the single-threaded
case faster, by not actually locking. Ideally, platform C libraries
would provide those stubs; however, pthread-stubs exists in large part
because of platforms that don't have those stubs. Having stubs even on
more common platforms is a more recent development, and potentially
problematic.
I don't have any fundamental objections here, but Linux isn't the
platform that really needs pthread-stubs in the first place. Could you
please seek out some feedback from people working on platforms that need
pthread-stubs for the core stubs, to find out how this might impact
them? I've CCed a couple of lists of potentially interested folks.
If a few non-Linux platform developers ack this, that would help; I
don't think a change like this should go in with the review coming
exclusively from Linux developers. :)
