On 3 November 2016 at 21:13, Josh Triplett <[email protected]> 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
