[haiku-commits] Re: haiku: hrev49583 - in src: servers/launch kits/app

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Fri, 28 Aug 2015 11:54:43 +0200

On 28.08.2015 10:39, Axel Dörfler wrote:

Am 28/08/2015 um 10:14 schrieb Ingo Weinhold:
On 28.08.2015 09:35, Axel Dörfler wrote:
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.
Wouldn't it suffice to call load_image() but wait with actually resuming
the main thread? Not exactly placeholder teams, but already pretty close.

As a temporary workaround, this might work, too. For long term, I think
this would bind too many resources for jobs that might never run.

For example, the print server will only be started on demand in the
future, but might never be used.

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.

Long term, this is not the optimal solution, though, as it would be nice
to send a message to a team without having to wait for it to be started,
ie. send the message and go on. Not all messages need an immediate
reply.

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.

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). And it also cannot work in cases where applications use find_port() and get_port_info() to get the target team ID. 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.

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. It might even be detrimental, if (e.g. application internal) messages depend on the application state, which may not be the same after restarting.

CU, Ingo


Other related posts: