Re: Proposal: complete thread support for glib.

[Sebastian Wilhelmi <wilhelmi ira uka de>]

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

Okay, I've implemented rwlocks where writers will gain precedence over
readers. 

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

I removed it.

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

He didn't complain ;-) so it is checked in as of now. 
Please test it hard. I'm pretty sure, there will be problems on some platforms
with the thread support. So we should change the discouraging message to use
glib-1.2 instead of glib-1.3 to something saying, that they should run make
check, which in turn should show the most problems with implementations. 

There's another thing, I want to hear somebodys opinion about: Do we really
want to have the stacksize argument? There is actually no way to portable
determine this for a programmer. Linux ignores it (It uses dynamic stacks). We
would on the other hand throw away flexibility, which might be of some use.
The best thing would be to make a g_thread_create function with only
thread_func, arg and joinable arguments and a g_thread_create_full function
with all parameters.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |      är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi   |