Thomas Munro <thomas.mu...@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
