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