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: Mike Smith <email@hidden>
- Date: Thu, 17 Mar 2005 10:33:38 -0800
Jim,
I'm in over my head at this point when it comes to giving accurate
advice; I appreciate you're terribly busy...
On Mar 17, 2005, at 1:04 AM, Stéphane Letz wrote:
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?
I'm going to leave this one to Jim. Your conclusions look correct to
me, but I'm not the authority on this.
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.
(leaving this text for context)
= Mike
_______________________________________________
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