[openbeos] Re: 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
there.
> 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,
anyway.
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).
Bye,
Axel.
Other related posts:
