[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 17:00:09 +0200

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.

Ah, right, indeed ;-)

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.

TBH, I don't know which authentication manager you're talking about.

The one you implemented in the registrar 8-)

Finally, you know how BLooper works: If a message has been read from
the port, that doesn't mean it has been handled. So there remains a
race condition anyway. We would need a new low-level messaging
mechanism to avoid that.

That's true, but I hadn't thought of that (either). For our messaging facilities it wouldn't be as useful.

It would also allow application restarts due to changed
configuration without losing the connection to it.
That sounds useful. However, it could as well be triggered actively
by the application itself (shut down BApplication, hand over port to
the launch daemon, exit/exec).

Indeed, but then transferring areas wouldn't work either in that time frame.

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

Bye,
Axel.

Other related posts:

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