Re: Using dead notification with mach ports
Re: Using dead notification with mach ports
- Subject: Re: Using dead notification with mach ports
- From: Jim Magee <email@hidden>
- Date: Fri, 10 Sep 2004 16:20:25 -0400
On Sep 10, 2004, at 12:47 PM, Stiphane Letz wrote:
I was thinking that doing the "task_get_bootstrap_port" and
"bootstrap_look_up(fBootPort, "server", &fServerPort)" code on the
client side (each client does that) was actually creating a new port
for each client, but it seems this is not the case? All clients see
the same "server" port allocated by the server? Is that correct?
SInce the name "port" is sometimes interchangeably used to talk about
the end-points of the communication channel and to talk about the
channel itself (i.e. the message queue), I can understand your
confusion. I will try to use "message queue" when I mean that.
There is only one Mach message queue in this case. That's the one the
server creates and then copies a send right to it into the bootstrap
namespace (via the bootstrap_register() RPC). When each client does a
bootstrap_look_up() RPC, they are each copied a send right to that
single Mach message queue (as part of the reply to the RPC).
The thing is that doing this way the server was able to handle RPC
call from all clients in the "mach_msg_server" call.....
And that can continue regardless of whether there is a single message
queue (directly passed to the mach_msg_server() call) or multiple
message queues added to a portset and then that passed to the
mach_msg_server() call instead.
When you say "the server creates a new, private, Mach port for the
client and adds it to the portset that it waits on", do you mean the
server will create a additional port for each client and this
additional port can be used also to make RPC calls from the client to
the server?
Yes.
Then when you say "The server can then request a "no-senders"
notification " do it means that the server has to use the
"mach_port_request_notification" fucntion (not the client as I was
doing..)
Yes, but now requesting a MACH_NOTIFY_NO_SENDERS notification.
So the system would be :
1) server first create the "server" port
(bootstrap_register(fBootPort, "server", fServerPort)...) A kind of
general entry point.
2) client get this port (task_get_bootstrap_port and
bootstrap_look_up(fBootPort, "server", &fServerPort) to get this port
to communicate with the server
3) client do a RPC call to register itself :
- server receives this RPC call and create a new private port for the
client
- server add the new private port in its portset
- server request a "no-senders" notification on the new private port
4) client get this new private port from the server (same method as 2 )
This is where you went astray. The clients wouldn't look the new
message queue up in some global namespace, but instead it would be
returned to them (privately) as part of the reply to this "connection
request" RPC.
5) client uses its private port to do RPC calls to the server
6) if client goes away, they the server receives a notification on the
client private port and thus know which client went away
Is this the idea?
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.