Re: Proposal: complete thread support for glib.

[Jeff Garzik <jgarzik pobox com>]

Sebastian Wilhelmi wrote:
> 
> 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.

I really like it so far, from the couple short test programs I have
run.  I have been waiting for this in order to do some portable thread
programming.  Thanks much for doing all this thread work.  :)


> - why aren't there any cancelation routines?
>   I don't think cancelation is necessery at all.

Agreed.  Cancellation is very messy and IMHO should not even be in the
POSIX API.


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

Please provide these.  Some systems have specific rwlock primitives
(like some parallel machines, among others), and on others we can use
the default implementation, built upon other glib primitives.

rwlocks _are_ a common solution which is re-implemented over and over
again.  There are many times where a key data structure in a program is
searched many times, but updated infrequently.  We might as well have
explicit rwlock support, rather can implicit (ie. easily built from
other glib primitives)


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

Vote seconded.  nspr is really parallel to what gthread is/does.

If TimJ doesn't have any problems I say check it in.

	Jeff