[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: