fun facts: - glib has, for some reason, a library constructor - which creates thread-local storage - which is configured with a destructor pointer within libglib - the library destructor does not destroy said storage - some libs you may want to dlopen()/dlclose() may link glib
-
Show this thread
-
so, if you dlopen() something that links against glib, dlclose() it, and then exit the thread you dlopen()'d on, your pthreads implementation will attempt to jump into wherever glib used to be mapped before you dlclose()d it and your program will, if you're lucky, segfault
1 reply 3 retweets 12 likesShow this thread -
"your program will, if you're lucky, segfault" is not a clause you want used to describe a scenario you find yourself in
2 replies 11 retweets 30 likesShow this thread -
this is the part where the musl devs go "I told you so" about using dlclose() and act smug about how their implementation is a no-op
2 replies 2 retweets 22 likesShow this thread -
-
Replying to @RichFelker @11rcombs
do yall implement thread-local-storage destructors as noops too?
1 reply 0 retweets 0 likes -
No. There are at least 2 types of TLS dtor. Keyed ones have dtor semantics specified by POSIX and C11. C++ ones are implemented by gcc on top of the former.
1 reply 0 retweets 1 like -
Arguably libc should provide a higher-quality C++ TLS implementation, but due to a design flaw in the ABI, it's impossible to do robustly without 800% memory overhead.
1 reply 0 retweets 1 like
So since we can't actually make it better than what gcc already emulates without ridiculous overhead, for now we just let gcc be the one to do it [wrongly].
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.