The problem that remains is what happens when a libxml is statically linked into a DLL whose threads come and go. In this case, the DLL may have its own DllMain() that must release thread-local global data when it receives a DLL_THREAD_DETACH message, and we don't provide a way to do that. The only solution I see is to add some sort of xmlFreeThreadGlobalState() API that would release the current thread's global state data, to be called when a thread is detaching. I'm a bit reluctant to propose such a thing in the absence of a use-case to test against. (I'm sure such a case will wander by eventually.) So, as far as I'm concerned, your patch to my patch is good. Maybe Igor will have something to say, if we can recall him from the philosophical weeds he wandered into in a recent post. :-)
Okay, I haven't run into problems (yet), so here is the consolidated patch (threads1.diff). To summarise, it introduces 2 things (windows only): - per-thread data are maintained in a linked list and xmlCleanupThreads deallocated any remaining per thread data; this permits unloading libxml2 while threads that have been using it are still alive - a LIBXML_STATIC_FOR_DLL compile-time flag that permits linking libxml2 statically inside a dll while using the most efficient TLS mechanism There is also a second patch (threads2.diff) with my suggestion for the last issue mentionned above. The documentation for LIBXML_STATIC_FOR_DLL could then say sth like "To be linked statically inside a DLL, libxml2 must be built with both LIBXML_STATIC and LIBXML_STATIC_FOR_DLL defined. In this mode, DLLs should call xmlDllMain from their own DllMain." For your reviewing pleasure ;-) -sbi
Attachment:
threads1.diff
Description: Binary data
Attachment:
threads2.diff
Description: Binary data