Re: Sending notification from a time-constraint thread
Re: Sending notification from a time-constraint thread
- Subject: Re: Sending notification from a time-constraint thread
- From: Stéphane Letz <email@hidden>
- Date: Thu, 17 Mar 2005 10:04:57 +0100
Le 16 mars 05, à 22:10, Mike Smith a écrit :
On Mar 16, 2005, at 12:57 PM, Stéphane LETZ wrote:
In a server/client system we are developing, we need a
time-constraint
thread in the server to send a notification to another thread in the
server. We use MIG generated RPC calls to communicate between
threads.
Why do you do this?
Because the server "non time-constraint" thread already "listen" to
RPC calls coming from clients.
So the idea was to use the same RPC system for server inter-thread
communication also.
Ok. But this then puts your time-constraint thread at the mercy of
the other thread's workload, as you have discovered.
Ok. To be sure I've understood correctly: when using RPC:
- an asynchronous call (simpleroutine) *without* timeout will return
immediately if the receiver queue is not full
- an asynchronous call (simpleroutine) *without* timeout will block if
the received queue is full
- an asynchronous call (simpleroutine) *with* timeout will return
immediately if the receiver queue is not full
- an asynchronous call (simpleroutine) *with* timeout will return an
"error (ipc/send) timed out " message if the receiver queue is full
Is is correct?
Unless you mean "between client and server", you
would generally be much better off implementing a trivial messaging
system
using posix condition variables.
Is is possible to have the server thread answer to RPC calls and
handle condition variables at the same time?
No; if it's blocked waiting for an incoming RPC, it can't also block
waiting for a cvar.
Your best bet is probably to have a helper thread blocked on the cvar,
which will turn around and message the server thread as needed. This
decouples your TC thread from the RPC; depending on your architecture
you can have this helper thread handle fan-in for multiple TC threads.
It's a bit miserable needing yet another thread, but the realities of
queueing (RPC) vs. asynchronous messaging (cvars) mean that you need a
transition interface of some sort.
OK. Thanks
Stephane Letz
_______________________________________________
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