Re: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
Re: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
- Subject: Re: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
- From: Stéphane Letz <email@hidden>
- Date: Mon, 13 Sep 2004 18:14:50 +0200
You seem to have an overly complex situation here. You have a private
client->server port, a call-back port, AND a shared semaphore.
Well after thinking a little more, maybe using only *one* port and the
shared semaphore for each client will be enough....
I mean the idea to have a "private" client->server port was to allow
the server to get a notification related to a specific client and to
cleanly destroy its internal client data structure. But if a call-back
port is needed for server->client communication anyway, *and* if this
port can be checked by the server for dead-name notification then the
"private" client->server port seems not to be needed anymore.
And *all* client->server MIG RPC can use the server global port
(allocated and registered in the global namespace)
Is this possible?
That's a lot of stuff to keep coordinated. I assume that you would
consider having any one of these channels shut down prematurely as a
sign of a failed client/server connection. If so, you have to request
a dead-name notification on the semaphore and the callback port, and a
no-senders notification on the private client->server port.
But if you are careful with checking error codes (and not allowing
the server to get hung up waiting for a non-responsive/dead client on
the semaphore and callback operations) you could still get away with
just the no-senders notification on the private client->server port.
For the semaphore, I guess "semaphore_signal" called on the server side
will return KERN_TERMINATED error code if the client has shut down
prematurely. Will it be enough?
For callback ports, I hope that using a timeout will be enough.
Another question : notification will allow the server to know when
clients disappear abnormally. What happens in the contrary case? Can
clients be notified if the server disappear?
Sure. But this is usually trickier unless you own all the clients
yourself. You can use a dead-name notification on the client->server
private port or a no-senders notification on the server->client
callback port. Again, the no-senders approach is usually the
cleanest. Since you are likely to be using a CFRunLoop in the client,
you probably are already creating a CFMachPort in the client to
receive the callbacks from the server. Unfortunately, CFMachPort
doesn't have any built in support for no-senders notifications (like
the invalidation callback for dead-name notifications). Instead,
you'll just have to request the notification manually and then handle
the no-senders notification as part of you normal message callback
handler.
Well I am not using CFMachPort because I wanted to have the server do
RPC on the call-back port. So I actually use the MIG generator to
define RPC to be called by the server. And I use a "manually" allocated
thread to handle the MIG generated message handling routine.
Would using CFRunLoop and CFMachPort be a cleaner approach?
Why is the "no-senders approach" the cleanest in this case?
Thanks
Stephane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden