RE: [xml] Windows threading issues

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

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 
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 
In this mode, DLLs should call xmlDllMain from their own DllMain."

For your reviewing pleasure ;-)


Attachment: threads1.diff
Description: Binary data

Attachment: threads2.diff
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]