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

[Emil Velikov]

On 3 November 2016 at 21:13, Josh Triplett <josh at freedesktop.org> wrote:
> 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. :)
Indeed and thank you.

So I take it that my analysis does sound about right ? Either way
it'll be great if more people give the scenario mentioned a test [on
their platform of choice].

Cheers,
Emil
P.S. From a quick look FreeBSD still has the DSO [1], while OpenBSD
have grown a completely different pthread-stubs :-\

[1] https://github.com/freebsd/freebsd-ports/blob/d7cb557b47478b4047ff701030e9309f957ab6b2/devel/libpthread-stubs/pkg-plist