Re: [xml] Windows threading issues

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

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

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
So, my questions:
1) Does my assessment that libxml needs a patch to work in my scenario make
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).


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