[haiku-commits] Re: haiku: hrev49583 - in src: servers/launch kits/app
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 28 Aug 2015 09:35:53 +0200
Am 27/08/2015 um 22:08 schrieb Michael Lotz:
The problem with the registrar wasn't in the BMessenger becoming
"outdated", but in the returned launch data giving the team_id of the
launch_daemon instead of the one for the registrar itself. The fix I
previously introduced that checks for team == current_team() therefore
didn't work when this happened. This caused the registrar to eventually
still send a message to its own port during init (in the BClipboard init
in this case) which couldn't possibly ever get handled.
Ah, that makes more sense, thanks!
[...]
Since get_port_info() is public, it's hard to tell how many external
applications also rely on this assumption. At least cortex demonstrates
a reasonably valid use case by getting the remote team via
get_port_info() and then using be_roster->GetRunningAppInfo() on that
team_id to display information.
Yes, the question is what they will be using this information for.
The area issue is a real show stopper, though, and I must admit I forgot
about the issue that the initial ports stay in the launch_daemon team
forever.
[...]
In conclusion I think that creating the ports in the launch_daemon in
the first place just isn't a very good idea. Can you elaborate on why it
should work that way? I presume to keep the ports around between service
relaunch and possibly for demand triggered launching?
Yes, but that's not all of it. This is also what makes it possible to
really start everything in parallel without having to worry about
dependencies between applications (as long as they use that service).
Have you read my launch_daemon introduction blog post by any chance? ;-)
This is what sets launchd/systemd and our launch_daemon apart from other
init systems (like Ubuntu's upstart).
It's not something I'd like to lose. I would rather invent some
mechanism to overcome the team ID issue, like placeholder teams, that
will automatically resolve to the assigned team. Once a team starts it
would need to take over all of its areas, ie. a mechanism similar to
fork(), just with completely different semantics.
However, once something like that is in place, we can just change the
launch_daemon configuration to declare all servers to legacy ones, and
express the dependencies via "requires".
Unfortunately, there is currently no mechanism to know when a
requirement is fulfilled other than having launched the team; you cannot
know when they will open their communication channels. For
BApplications, one could wait for their app registration, though, but
this is not implemented at this point.
Bye,
Axel.
Other related posts:
