RE: [xml] Windows threading issues

[Jesse Pelton <jsp PKC com>]

> -----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.

OK.

> 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
> DLL_THREAD_DETACH dance in LIBXML_STATIC_FOR_DLL mode?
> 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
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. :-)