[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Tom Bachmann |
Subject: |
Re: Reliability of RPC services |
Date: |
Mon, 24 Apr 2006 21:42:02 +0200 |
User-agent: |
Mail/News 1.5 (X11/20060403) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan S. Shapiro wrote:
> On Mon, 2006-04-24 at 20:46 +0200, Tom Bachmann wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jonathan S. Shapiro wrote:
>>> 1. Incoming messages on any valid, unblocked FCRB.
>>> 2. Especially, incoming idempotent messages.
>>>
>>> So one way to guard against a failing server is to use idempotent timer
>>> events to implement a "heartbeat" -- in much the way that TCP does.
>>>
>> I don't get it. What do we gain from artificially awaking M? Is the
>> FCRB->M C invoked still blocked after step 5?
>
> We need to avoid words like "blocked" in this discussion, because that
> is what is causing the confusion.
you used it (``1. Incoming messages on any valid, unblocked FCRB.''), i
just quoted you.
> First, let me repeat the steps for
> reference:
>
>> 1. C has invoked some FCRB->M, passing some RFCRB->C
>> 2. C yields the CPU
>> 3. M has been activated by arrival of C's message
>> 4. M has invoked some FCRB->S, passing some RCFRB->M
>> 5. M yields the CPU
>> 6. S has been activated by arrival of M's message
>> ?. S *may* eventually invoke RFCRB->M, but cannot be
>> sure. This is the ``problem.''
>
> To answer your question, it isn't important whether FCRB->M is available
> after step 5. This depends on whether M wishes to be multi-threaded.
multithreaded in what sense? the continuation style of programming?
> This really has nothing to do with the problem we are trying to solve,
> which is that S may fail to return to M.
>
yes. your explination makes this clear.
- --
- -ness-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFETSoKvD/ijq9JWhsRAnwgAJ42VfM0fHm9aiS0DC/a2DRzD4olPgCfUBJw
qy5I2cn22c/N38wQhZRt2lU=
=YxDt
-----END PGP SIGNATURE-----
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/22
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/23
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services,
Tom Bachmann <=
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
RE: Reliability of RPC services, Christopher Nelson, 2006/04/25