Proposal: complete thread support for glib.
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: Gtk Development List <gtk-devel-list redhat com>
- Subject: Proposal: complete thread support for glib.
- Date: Tue, 01 Jun 1999 16:35:56 +0200
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
--
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 |
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]