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

  • From: Michael Lotz <mmlr@xxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Fri, 28 Aug 2015 23:19:46 +0200

Hi

I have taken the liberty to go ahead and implement a solution based on
the points in this discussion and pushed it in hrev49591.

On 28.08.2015 17:00, Axel Dörfler wrote:

Am 28/08/2015 um 14:18 schrieb Ingo Weinhold:
Yes, but this makes creating the port by the launch_daemon
completely superfluous, doesn't it?
It makes the communication channel available a lot earlier. That
seemed to be one of your concerns.

The ports are still created in the launch_daemon to get this benefit.

You are not supposed to find launch_daemon created ports by name.
They may have any name; the launch_daemon chooses them.
You got it the wrong way around: Since some existing uses of
get_port_info(), as Michael wrote, it may not be possible to have
those ports be created by the launch daemon. Obviously we can
adjust the code in the repository and on HaikuPorts, but
introducing new rules for existing APIs may break preexisting
applications.

get_port_info() is not an issue (at least it won't with the correct
team ID). find_name() cannot be used to find a port that has been
created by the launch_daemon, nor is it supposed to be used for this.
We had three named ports in our system, one for the app_server, and
two for the registrar. None of those was bound to any compatibility
issues, so I'm not sure what you are referring to here.

The "race condition" of possibly finding ports while they have not yet
been transferred to the target team does now exist and there is no real
way around it. Based on the logic above I deemed this acceptable.

If it should actually become a problem, we'd probably need kernel
support for fixing this. The ports could for example be created
"ownerless" in which case they wouldn't be returned from find_port() and
a later set_port_owner() would automatically "publish" them. Such a
mechanism would fit this use case perfectly.

Though, what do we actually get? The crash example doesn't sound
that convincing.

It probably only moves the complexity of reconnecting from the
client to the server. Unless the client is an API which implements
this correctly, I think that's a good thing. For stateless
communication, it actually just removes complexity. Also a good thing
in my book :-)

Generally I'm sceptical when it comes to providing a generic solution
for abstracting application communication. It might work for some applications/servers that use simple forms of communication, but I
wouldn't want to model more complex scenarios within the launch_daemon.

Few applications are truly stateless, so there would probably be a need
for more complexity to make things work, although I can see how the
launch data mechanism could already work for some cases.

Personally I'd rather avoid introducing too many dependencies between
applications and the launch_daemon as well. I'd prefer a clean API
within libbe that helps abstracting reconnections for example. This is already done in the case of the media_server AFAIR.

Regards,
Michael

Other related posts:

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