[Xcb] [PATCH pthread-stubs 0/4] Rework pthread-stubs design/implementation

[Josh Triplett]

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. :)