[haiku-appserver] Re: [openbeos] Launching the input_server from the app_server...

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx, "Haiku app_server" <haiku-appserver@xxxxxxxxxxxxx>
  • Date: Fri, 22 Dec 2006 11:30:10 +0100 (MET)

"Ryan Leavengood" <leavengood@xxxxxxxxx> wrote:
> But there are still a few things I'm wondering:

BTW the best place for this discussion would be the app_server mailing 
list :-)
I forwarded to that one as well, so please let's move the discussion 

> 1. What is the best way for the EventDispatcher to notify the desktop 
> that it has stop processing events and therefore the input_server has 
> stopped running? What I have done so far is to have a Desktop* member 
> in the EventDispatcher which is set in Desktop::Init() 
> (fEventDispatcher.SetDesktop(this)), and then when the event 
> processing 
> loop ends in EventDispatcher, fDeskop->
> PostMessage(AS_LAUNCH_INPUT_SERVER) is called. I don't know if I like 
> this since it introduces a sort of circular dependency (though in a 
> sense this already exists since the EventDispatcher owns a 
> KeyboardFilter and MouseFilter which also own Desktop pointers.) Any 
> other suggestions?

It's a common design pattern that an object knows its owner, and sends 
it a message on some special occurence.
If you don't want to keep a pointer to the desktop, you can also just 
store its message port, and send the message to it directly; but it's 
guaranteed that the event dispatcher is quit when desktop is deleted, 
However, I wouldn't call this message AS_LAUNCH_INPUT_SERVER - what 
happened is that its event stream got lost, the event dispatcher 
doesn't know anything about this stream; it doesn't have to be an 
input_server, it could well be some network stream or whatever. Maybe 
AS_EVENT_STREAM_LOST/GONE/whatever would be more appropriate.
The Desktop itself will then try to restore the previous event stream - 
which, for now, is always the input server, of course. 

Notice, however, that current servers (including the input_server) run 
as an application in that desktop anyway, so they will be quit when the 
desktop object is discarded. But since that's a future extension to 
multi-user anyway, it doesn't matter that much for now.

> 2. How should the input_server be launched in 
> Desktop::_LaunchInputServer? I was thinking of copying some of the 
> code 
> from the older commented-out _LaunchInputServer in AppServer.cpp that 
> calls load_image, etc. But I was thinking that now that the Registrar 
> is started before the app_server, maybe somehow the Registrar could 
> be 
> used? Again, any suggestions would be appreciated.

Since our app_server links against libbe.so, and our registrar is 
already working, BRoster::Launch() should work fine, I'd guess. If not, 
load_image() could still be used.

> 3. One small little detail. Axel talks a little about this in the 
> above 
> message, but I'm still wondering that if the EventDispatcher is 
> supposed to _Unset itself when the event loop ends, this could cause 
> some sort of deadlock since _Unset calls wait_for_thread on fThread, 
> which would be the thread calling _Unset from the loop. I guess my 
> main 
> question is what happens if wait_for_thread is called with the 
> thread_id of the current thread? Axel sort of hinted that maybe 
> fThread 
> should be set to some error value before _Unset is called. In my 
> current code I do this by setting fThread to -1 before calling 
> _Unset, 
> but I'm wondering if this is unneeded. So far I haven't tested this 
> since I haven't done 2 above yet.

Currently, the kernel does not check if you're waiting for yourself 
(which will always just block forever until someone kills you, or 
interrupts you with a signal). It's the same on BeOS, so I'm not sure 
we can change this; I think it would make more sense to return 
B_BAD_VALUE in this case - if you just wanted to wait forever until a 
signal you could do this via sleep(B_INFINITE_TIMEOUT).


Other related posts: