RE: [xml] Windows threading issues

-----Original Message-----
From: Stéphane Bidoul [mailto:stephane bidoul softwareag com] 
Sent: Monday, July 21, 2003 9:55 AM
To: 'Jesse Pelton'
Cc: xml gnome org
Subject: RE: [xml] Windows threading issues

xmlInitThreads is called from xmlInitParser, and
xmlInitParser *must* be called by a "main" thread before
any other call to libxml, so it should be okay to leave
the initialization in xmlInitParser only.
I did that in the attached patch.


Daniel and Igor are better judges for this.
There were a few bugs in the linked list manipulations
coming from Eugene's changes.
Fixed in the attached patch.

Good catch!

I also changed the #ifdefs in xmlCleanupThreads
to free the linked list in pure DLL mode too
(in case libxml is shutdown before threads terminate).
Does that makes sense to you?

Finally, I removed the DLL_PROCESS_DETACH code,
because xmlCleanupThreads must have been called before
unloading the dll anyway.
Does that makes sense to you?

Yup, this all hangs together.  It's also less code and easier to read
without the long #ifdefs, which should ease maintenance.

Finally, isn't there still a problem for your
original scenario? How will you do the
You defer freeing of TLS until xmlCleanupThreads,
but that's a bit late if your process creates and
destroys many threads: TLS memory will accumulate
until libxml shutdown.

Well, there's a problem, but I don't think it actually affects me.  I'm
running in IIS threads that get terminated without receiving a
DLL_THREAD_DETACH message.  As near as I can tell, once IIS fires up a
worker thread for handling a request, it leaves the thread running until it
shuts down the whole DLL.  Thus, there's neither opportunity nor need for
cleanup until shutdown.  Calling xmlCleanupParser() in ExitInstance() takes
care of the shutdown case.

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 philosophical
weeds he wandered into in a recent post. :-)

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