Re: Reliability of RPC services

[Tom Bachmann]

-----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-----