Re: [xml] win32 thread safety patch

["Robert Collins" <robert collins itdomain com au>]

----- Original Message -----
From: "Igor Zlatkovic" <igor stud fh-frankfurt de>

> In the case of the API implementation, whenever TLS is allocated for a
> thread through a call to xmlGetGlobalState(), the patch fires another
thread
> which waits for the caller thread to finish and then frees it's global
> state. This efficiently results in having twice as many threads as was
the
> intention, the one half working, the other half waiting to clean up
after
> the first half. Hm... Why? Well, the API implementation of TLS in
Windows
> does not have a way to specify a desctructor function, like f in
> pthread_key_create(k, f). Instead, MS documentation says that every
thread
> is responsible for freeing the memory it allocated, or that was
allocated
> for it, manually. Serguei decided to rather have the double on threads
than
> to leak memory per thread.

I haven't reviewed the patch yet (I will this weekend) but it seems to
me that having a) a single worker thread for freeing the TLS data, or b)
create your own trivial wrappers that give you pthread_key_create and
pthread_key_delete functionality are lower overhead ways to achieve the
same thing.

If libxml is GPL compatible you can borrow the Cygwin pthread_key*
functions (which use the Win32 API) or those from the other pthread for
win32 library I mentioned which are LGPL.

Rob