[Top][All Lists]
[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
signature.asc
Description: Digital signature
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/23
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/23
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/29
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/29
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/29
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/29
- Re: Reliability of RPC services,
Bas Wijnen <=
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/30
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/30
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/22
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/22
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/22
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/23
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/23
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/23
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/24