On Thu, 10 Apr 2025, Corinna Vinschen via Cygwin wrote: > > It seems glibc takes care of this implicit deregistration in > > __cxa_finalize, after calling __cxa_atexit functions, it unregisters any > > at_quick_exit or pthread_atfork callbacks from the DSO being unloaded. > > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/cxa_finalize.c;h=2bb35602edc6bf842e5d2c93ad03454d7b57ee65;hb=HEAD > > > > It doesn't look like newlib deals with either at_quick_exit or > > pthread_atfork handlers in its __cxa_finalize implementation. > > Cygwin is doing this stuff mostly in its own code, see thread.cc. > It keeps lists of the callbacks in a global structure which is > called MT_INTERFACE throughout thread.cc. > > The functions pthread::atforkprepare(), pthread::atforkparent() and > pthread::atforkchild () are called from different spots during fork(). > > Here's what we're missing: > > - Either keep track of the DLL a callback function is coming from by > calling dlls.find (handle, true) and store the struct dll pointer. > In dlclose(), if the DLL is of type DLL_LOAD or DLL_NATIVE, and > the refcounter indicates that this is the last FreeLibrary, check the > three callback lists in MT_INTERFACE and remove all functions > with the same struct dll pointer.
I'm inclined to take this approach. What about at_quick_exit though? That's entirely within newlib, isn't it? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
