[cairo] WGL backend for glitz?

[Tor Lillqvist]

Hi again,

I have now been hacking on a WGL backend for some evenings. As was
suggested, I made copies of the *glx* files and started from that. I
don't have yet any code that actually does anything (not all of my
*wgl* files even compile currently). But at least I think I have some
understanding how it all is supposed to hang together.

Except for some points... Mainly the thread stuff. Is the thread
support supposed to work in the GLX and AGL backends, or is it just an
outline to be fixed later? (I am looking at glitz-0.1.5.)

The glitz_glx_thread_info_get() function allocates a thread_info
struct and sets it as a thread-local value for the info_tsd key only
once, the first time it is called. Other times it fetches the
thread-local thread_info with xthread_get_specific(). But where is the
thread-local thread_info allocated and set for the other threads?
Doesn't xthread_get_specific return NULL if no value has been set for
the key, which will cause a crash in the caller of
glitz_glx_thread_info_get()? Ditto for the AGL backend.

Anyway, on Win32 the equivalent of xthread_key_create() (TlsAlloc())
doesn't take any destructor function. A workaround would be to have a
thread function wrapper in glitz, and require that threads that are
going to use glitz have that as their thread function.

Another workaround would be to require that glitz-wgl is built as a
DLL (a very reasonable requirement IMHO), and write a DllMain() to
watch thread creation and destruction, and call the destructor for
thread_infos as needed. (This approach does have some problems,
though. Google for USENET postings about TlsAlloc and destructor.)

Which sounds better? Or should I just ignore threads on Win32 for
now...?

P.S:

I am leaving for vacation for three weeks on Saturday. Even if my WGL
code isn't working yet by then, should I submit it for inclusion? Or
do you prefer to have a look at it only when it actually works?

--tml