Thomas Munro <thomas.munro@gmail.com> writes:
> ... and that NetBSD also chose the same arbitrary value for their
> threading stub library:
> https://github.com/NetBSD/src/blob/trunk/lib/libc/thread-stub/thread-stub.c#L392
> ... as they are entirely within their rights to do?
I poked around in that repo, and found the non-stub version of
pthread_self:
https://github.com/NetBSD/src/blob/trunk/lib/libpthread/pthread.c#L863
Relevant to this discussion is that it actually redirects to the
stub version if __uselibcstub is still set, and that variable
appears to be cleared by pthread__init,
https://github.com/NetBSD/src/blob/trunk/lib/libpthread/pthread.c#L187
whose header comment is pretty telling:
/*
* This needs to be started by the library loading code, before main()
* gets to run, for various things that use the state of the initial thread
* to work properly (thread-specific data is an application-visible example;
* spinlock counts for mutexes is an internal example).
*/
I've not found the mechanism by which pthread__init gets called, but
this sure smells like they think it only has to happen before main().
Interestingly, some of the other files in that directory have recent
CVS log entries specifically mentioning bug fixes for cases where
libpthread is dlopen'd. So it's not like they don't want to support
the case. I wonder if they just need to fix pthread_self to forcibly
init the library if __uselibcstub is still set.
regards, tom lane