Re: [xml] win32 thread safety patch

[Igor Zlatkovic <igor stud fh-frankfurt de>]

Hiya,

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

a) This is not any simpler than what Serguei did, but is a solution. I would
welcome a patch.

b) Well, when you take a look at the code of the pthreads-win32 library
(http://sources.redhat.com/pthreads-win32/), the pthread_key_create
functionality which enables a destructor function to be called is everything
but trivial.

Taking the required functionality from pthreads-win32 library would mean
taking a good part of it. More, we would then have one libxml2 binary for
the client code which uses C++ exception handling, one for the client code
which uses Windows structured exception handling, one for the code which
uses none of these but plays setjmp/longjmp, a myriad of binaries for a
myriad of possibilities other compilers might offer... Wouldn't it be a lot
better to use pthread interface in libxml2 and then link to the actual
pthreads-win32 library? An additional library it is, still I would welcome
it much warmer than repeating two thirds of it's functionality in libxml2.

If there is a way to implement pthread_key_* functionality trivially, so
that any client code can link to the same binary and work, I would, of
course, love to see it.

Ciao
Igor