Re: [xml] Windows threading issues

[Igor Zlatkovic <igor zlatkovic com>]

Jesse Pelton wrote:
> I'm hoping someone on the list has enough experience with Windows
> multithreading and libxml (Igor? Stephane?) to help with a problem I'm
> seeing.
>
> The situation is this: I'm using libxml 2.5.8 (statically linked) in an
> ISAPI DLL running under IIS 5, and I'm not sure how to build the library so
> it cleans up its thread-local "global" data correctly. I started with
> LIBXML_STATIC defined (because it seemed like the right thing to do, since
> I'm statically linking to the library), but this often crashes at exit.
> (There's a cleanup thread that calls WaitForSingleObject(), but by the time
> the wait returns, the thread's code has been unloaded, leading to an access
> violation.) 

IIS is notorious for its threading. I have seen it before, unloading DLL 
code from memory with a dozen threads still sleeping. When one of these then 
wakes up, the OS scheduler will load the CPU registers with the context of 
that thread and the instruction pointer will point into the blight.

An IIS extension may therefore never create threads. Only the web server may 
do it and the extension must be fully reentrant. IIS can and will unload any 
DLL at whim and any thread left over will, at best, kill the whole process 
as soon it comes awake. It can come worse, of course, instruction pointers 
pointing into the oblivion are nothing short to paradise for those who seek 
to have the server execute arbitrary code.

This means that the thread-enabled libxml cannot be used anywhere in an IIS 
extension. It doesn't matter wether you link statically or not, as long 
libxml creates an extra thread, things will go wrong.

> If I leave LIBXML_STATIC undefined, theory has it that libxml's
> DllMain() will use DLL_THREAD_DETACH and DLL_PROCESS_DETACH calls to clean
> up properly - but then libxml's DllMain() conflicts with my own. If I were
> to remove libxml's DllMain(), my own DllMain() couldn't clean up, because it
> wouldn't have access to required static variables.

You must #define LIBXML_STATIC if you link statically. There is no way 
around it.

> It looks to me like libxml is not presently designed to work as a library
> statically linked into a DLL. 

No, rather Windows thread API wasn't designed for usage in a module which 
doesn't control thread creation and termination, be it a static library, 
dynamic library, whatever.

> If I'm right, a solution might be to make
> libxml's DllMain() conditional on another preprocessor constant and add a
> cleanup function that either libxml's DllMain() or another DllMain() could
> call.
>
> So, my questions:
> 1) Does my assessment that libxml needs a patch to work in my scenario make
> sense?
> 2) If so, does my solution make sense, or is there a better approach?
>
> I'm happy to attempt a patch if necessary.

In the core of the problem, you must stop libxml from creating extra 
threads. When thread-enabled, libxml needs to associate a TSD key with each 
IIS's thread which calls into libxml. If you have a way to free this TSD key 
without creating an extra thread, then that is your solution. Possible ways are:
  1) Link dynamically to libxml.
  2) Make a thread-disabled libxml and do the sync from within your 
extension code, if needed at all.

Your idea about the new TSD destructor functions which you can call from 
within your DllMain is also doable, but I personally find the two solutions 
above easier, especially the 1).

Ciao,
Igor