l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services


From: Bas Wijnen
Subject: Re: Reliability of RPC services
Date: Sun, 30 Apr 2006 12:25:22 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Sat, Apr 29, 2006 at 10:24:24PM -0400, Jonathan S. Shapiro wrote:
> > > But in a scheduler activation design no process is ever waiting in this
> > > fashion. How should this be specified in a context of scheduler
> > > activations?
> > 
> > Even if technically the process isn't "waiting" for the reply, in practice
> > it will in fact be waiting in the sense that it cannot continue with
> > something until it received a reply.  This doesn't mean it doesn't do
> > other things, but it's waiting nonetheless.
> 
> But the test of interest here is not "is it waiting for a reply". That
> is harmless. The test of interest here is "is it prevented from getting
> useful work done".

No, the test which was meant here (for single-copy reply capabilities) was: Is
there ever going to be a reply at all?  If the server is conceptually
multi-threading (through an event loop, or even with real threads), then the
other threads may be getting lots of work done.  But once the last reply
capability for one thread is dropped (instead of used), that particular thread
will not get any work done anymore.  This can be detected, so the thread can
clean up.  Single-copy notify-on-no-reference is a method for doing this.
However, by now I at least a agree with you that the cost (performace hit on
all IPC) is too high for the limited problem that's being solved by it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]