[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Seeking advice on Threads & DO
From: |
Richard Frith-Macdonald |
Subject: |
Re: Seeking advice on Threads & DO |
Date: |
Sat, 19 Oct 2002 05:53:13 +0100 |
On Thursday, October 17, 2002, at 08:14 am, Chad Hardin wrote:
I’ve been working away at a SysV IPC based lightweight window manager
manager for about 2 weeks now. As you may know, handling many types
of events (with diff message lengths) with Sysv IPC involves a lot of
“grunt” work. All kinds of different structs for each type of message
and so forth, not fun.
So..
I’m considering whether I should instead use Distributed Objects. If
I could do this, it would save a LOT of work for me.
Since this is a lightweight window manager, no drawing code will be
sent to the server. The most frequent events it will handle will be
when clients calling a “getEvent” type method via a named NSConnection
get “MouseMoved” events. Since mouse moves will be the most frequent
event, Mouse moves events could accumulate in the mesasge queues
located in the server rather quickly (in NSMutableArrays), does
anybody think that this may become a bottleneck? I’m thinking it will
not, but you never know.
Probably not ... as long as the entire array is copied in one go rather
than item by item.
Also, the server will use the DirectFB lib, which uses it’s own event
system which will sleep when there are no events. Since NSConnection
uses the RunLoop to dispatch the messages to the shared object (*AM I
CORRECT HERE?*)
Yes.
then blocking is not good.
I’m thinking of splitting the server into 2 threads, one thread will
get the DirectFB events and the other will be the handle the gnustep
run loop. The DirectFB event grabbing thread will use objc stuff like
NSMutableArray (which will also be used by the gnustep run loop
thread), so there should be some locking here I think.
I’m thinking if I put locks after each respective event loop (after an
event is received) then it will work out. The goal is to globally
lock the entire app until the DirectFBs task of putting events into
the queues is done.
Could anybody offer me some insight into this? I remember a while
back a posted email in this list that said “do not use threads at
all”, is that still the case?
I don't recommend using threads at all, but not because they don't work
or anything like that.
Simply because threaded apps are really hard to debug and are
inherently inefficient (use of
*any* threading forces the system to start doing a lot of locking that
it can omit otherwise).
If the DirectFB library provides any way to do a non-blocking wait for
events, I'd use that
rather than threading. When using X for instance, you can ask the for
the file descriptor
X uses to communicate with the server, and add that descriptor to the
run loop so that the
actual wait for events is done in the run loop. Even if you can't do
it that way, you could
poll a non-blocking call to fetch events every 20th of a second for
instance.