[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 12:23:00 +0200

Am 28/08/2015 um 11:54 schrieb Ingo Weinhold:

But on second thought, and for the time being, since the port is
retrieved via the launch_daemon anyway, and the GetLaunchData()
reply will wait for the team to be launched now, it could now also
just return the actual port within the team.

Not sure I can follow you. I assume the print server would be
declared to be started "on demand". I can't find anything in your
blog post or the wiki page what that means exactly. I assume the
launch is triggered by some API call (GetLaunchData()? -- can't find
it)? In that case it is really irrelevant, as the application can
simply be started at that point. I suppose that's what you're
saying.

Yep, and it's called BLaunchRoster::GetData(), I mixed that up, sorry.
"On demand" would mean that the communication channels are created
upfront, but the actual service is only spawned when someone requests
the data; you could talk to the team immediately, and don't have to wait
for it to be ready to reply.

Now, since the GetData() reply is postponed until after the team has
started, it doesn't make much sense anymore to create them upfront.

For things with known addresses in the global namespace (like the
listening socket of an FTP server), this still makes sense, though.

If the respective application is started by a simple procedure --
create its app port, call load_image(), transfer the port, resume
main thread -- messages can be sent to the port right after it has
been transferred, i.e. long before the application has *really* been
started. I would find trying to enable even earlier message sending
a rather unnecessary optimization.

Yes, but this makes creating the port by the launch_daemon completely
superfluous, doesn't it?

If your idea of "on demand" launching is, that the application is
started when the first message is sent to it, then this obviously
cannot work with the current transfer by area mechanism (one could
start the application when a messenger targeting it is requested,
though).

Yep.

And it also cannot work in cases where applications use find_port()
and get_port_info() to get the target team ID.

You are not supposed to find launch_daemon created ports by name. They
may have any name; the launch_daemon chooses them.
This also makes it possible to have known ports for per user services;
the launch_daemon knows which port you need to talk to.

In both situations actually creating the (minimal/placeholder) team
up front is indeed the only option. I wonder however for what servers
this actually applies and if they aren't started on boot anyway.

I suppose not many if any; it might not be worthwhile to spend a lot of time on it.

Also, another idea was to keep the team available even if it
crashed; ie. the team could be relaunched, and no messages would
have been lost in the mean time -- at least for some things this
would make a difference without further effort (like Tracker, the
authentication manager, ...).
Neither in case of Tracker nor the authentication manager this seems
to be particularly useful to me.

All state-less "shoot message" or "request - reply" situations could benefit from this. I'm not aware that the authentication manager needs a context, and parts of the Tracker API could use this, too, like "open folder".
It would also allow application restarts due to changed configuration without losing the connection to it.

It might even be detrimental, if
(e.g. application internal) messages depend on the application
state, which may not be the same after restarting.

Yes, applications would need to be made aware of the fact; using global IDs internally instead of local ones to identify the state could solve this, though. For application where it's worthwhile, one could also recreate the former state if possible (like the app_server currently does).
That's okay, it's not meant that you get everything for free.

Bye,
Axel.

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 08-2015