RE: [xml] win32 thread safety patch

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

Hi there :-)

> The preprocessor inflation is somewhat extended due to
> the fact that the patch provides 2 native threading
> systems (which I don't really understand this seems to
> be a Windowsism, one requiring the MS compiler).

Yes, that is a headache sometimes. Windows has only one native threading
model. The patch differs between MS compiler and other compilers, not
between threading systems. The issue is the thread local storage (TLS, and
TLS = TSD, thread-specific data).

MS compiler has a declaration specifier which answers to the name
__declspec(thread) and that causes the compiler to allocate one instance of
the declared variable for each thread a program might create. When a thread
dies, the memory allocated this way is being freed automatically. This is a
compiler implementation of TLS and supported by MS compiler only.

There is also an API implementation of TLS. There are functions like
TlsSetValue() and TlsGetValue(). One would use pthread_setspecific() and
pthread_getspecific() with pthreads for the same purpose.

Now, Serguei's patch uses the compiler implementation of TLS if available,
and the API implementation otherwise.

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.

Ciao
Igor