The following message was also sent to gtk-devel-list.

Hi,

after a long time, where all of that actually already laid on my disk, I found
some time to write up this proposal.

I have uploaded glib-wilhelmi-990601.patch.gz to www.gtk.org/incoming.

It completes the thread support for glib. It includes a test program, which
actually helped me finding some nasty bugs in my code.

Here are some random thoughts:

- why an extra data structure for the task:
 I tried to do without. But that way its better. You might argue, that
 pthread_t is nicer that a pointer, because it is 'small'. You can use it as
 an index in an array. (at least on solaris, but I think, on linux too), but
 that is not true on many other platforms. There pthread_t is just a pointer.

- why introducing GStaticRecMutex?
 sometimes recursive mutexs are simpler to program that normal ones.
 LinuxThreads provides recursive mutexes natively, so it makes sense to wrap
 them and provide a fallback for other systems (all other now)

- why aren't there any cancelation routines?
 I don't think cancelation is necessery at all. As an example I want to
 mention, that the whole mozilla codebase doesn't use the posix cancelation
 routines at all, it however implements its own cancelation in nspr, but uses
 them only once in mozilla.

- why are there no rwlocks?
 Again, I think, they are mostly academic (not, that I also try to pretent to
 be academic;-). Again in mozilla, there is no call to the nspr rwlock
 routines.

- why is the nspr part of the implementations not updated.
 I would vote to remove that completly, because if nspr doesn't use the
 native thread system on a computer, but the user thread system, nothing will
 work, if you'r not using the io-functions of nspr, too. (You simply block
 the whole process, if you block on read in one thread.)

- why defining g_usleep?
 First, usleep is rather umportable. Second, it sometimes uses time signals,
 that wont work with threads att all. A sleep routine doesn't have to be very
 fast ;-), so select(...) should be fine.

Theres nothing more that comes to mind right now.
I hope you like this a bit, that we can get this in for 1.4.

Bye,
Sebastian