site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Jim, Ok. To be sure I've understood correctly: when using RPC: (leaving this text for context) = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. - 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. This email sent to site_archiver@lists.apple.com