Re: Rép : Using dead notification with mach ports
Re: Rép : Using dead notification with mach ports
- Subject: Re: Rép : Using dead notification with mach ports
- From: Jim Magee <email@hidden>
- Date: Mon, 13 Sep 2004 13:49:20 -0400
On Sep 13, 2004, at 1:30 PM, Stéphane Letz wrote:
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?
Should be, as long as the client always allocates the semaphore and
not the server.
Hum... I am actually allocating all semaphores on the server side and
returning them to the client like in the following RPC call :
StephaneConnectToServer ( serverPort : mach_port_t;
connectFlags : integer_t;
clientPort : mach_port_t;
out semaphorePort: semaphore_t;
out serverPort: mach_port_make_send_t );
The reason is that I have to pass client semaphore to other clients
(for inter-clients synchronization), thus when a new client register
to the server, it will get its own semaphore and the semaphore of all
already running clients. And all already running clients will be
"notified" for the new client semaphore.
When the system runs, only one client will be waiting on its private
semaphore, but the server or other clients will possibly signal the
semaphore.
So I think all semaphores have to be allocated on the server side.
What happens if the server use semaphore_signal in this case?
What is important for a Mach semaphore is which task it is associated
with at creation. If it is associated with the client task and the
client goes away, then operations on that semaphore by other tasks will
fail (with an appropriate error code). So, choosing which task to
associate with is important for widely shared semaphores.
But if I understand correctly what you explained about "dead-name" and
"no-senders" notifications, everything allocated on the server side
(the private client->server port and semaphores can be handled with
the "no-senders" notification.
You can never use a no-sender notification with a Mach semaphore. The
kernel holds the receive right. Everyone else only has send rights -
and you can't request a no-sender notification when you only hold a
send right to a port (even though this is a semaphore port rather than
a message queue port). Dead-name notifications (or just the error
returns from trying to use a semaphore whose's associated task has gone
away) are the way to go there.
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?
If you can handle it all in your helper thread, and the number of
clients needing this additional thread is small, then there is
nothing wrong with your approach. But it's normally better to not
create an additional threads in the clients if you can avoid it. If
the callbacks cannot be completely handled in the additional thread,
how do these additional threads signal the main thread? In that case,
you're going to have to reflect the callback status over to the main
thread anyway and it might have just been easier (and more efficient)
to send it there directly.
Do you mean i could handled notifications coming from the server (*in
the form of MIG generated RPC*) in the main application thread if I
use CFRunLoop and CFMachPort?
Sure. How do you think all the other CFRunLoop sources work? A
CFRunLoop is just a wrapper around a Mach portset. ;-)
--Jim _______________________________________________
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