[Glade-users] glade and thread-safe code...
- From: rdiazmartin yahoo com (Roberto Diaz)
- Subject: [Glade-users] glade and thread-safe code...
- Date: Tue, 14 Nov 2000 08:00:49 +0100 (MET)
GDK_THREADS_ENTER..
code which draws in a drawing area.. (is a loop)
GDK_THREADS_LEAVE.
Nope, you would have to place the global lock around the calls, not the
loop.
Well I was not explaining myself very well.. in fact I mean locks in the
calls.. bad pseudocode.. sorry.
I'm curious ... please read the following web pages from end to end and
then tell me how you can justify this additional effort of threads ...
'cause I haven't yet found a good justification.
http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm
Ok... you have very good points.. in fact the only advantage in a single
cpu system could be to "steal" more cpu time and cheat the scheduler.. (of
course depending of the implementation).. but this could be achieved more
seriosly giving more priority to the proccess..
But I agree.. locks gets a lot of overhead.. and context-switching is
really painfull..
But the same arguments could be applied to an multi-proccess model (such
as a http server like apache) why to fork? we could manage all with a
single proccess an events handlers.. OK the first reason is to isolate
memory usage which is not an excuse in a threaded model.. and once again
to "steal" more cpu time which we see is not a real excuse neither...
And now my question.. What are multi-threading good for in a linux system
with a single cpu? and for what are they really good in a SMP system?.. we
could give a single-proccess abstraction to the programer using a
well-designed kernel-api.
Very good... threads maybe are computer science "masturbation" or maybe
there are too much people with a lot of spare time ;)
To be or not to be... :)
Regards
Roberto
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]