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