resume capabilities

[Norman Hardy]

At 11:43 -0500 99/12/30, Kragen Sitaker wrote:
>Shap writes:
>> The reciprocal situation -- that the client can be starved by competition
>> for the server -- is not as compelling.  In deciding to call the server,
>> the client has already decided to trust the server.  If the server is
>> multiplexed the client has elected to trust the multiplexing decisions.
>> This is a completely separate matter from trusting other clients of the
>> same server.
>
>As far as I can tell, there are two ways to initiate bidirectional
>communication with another process:
>- call it and wait for it to return;
>- send to it, then return to somebody, and wait for it to call or send to you.
>
>Does this mean I must trust every process I communicate bidirectionally
>with not to let me hang forever?  Or is it expected that I will use
>trusted intermediaries, or spawn off another process to call me or send
>to me after a while in case I'm hung?
>

Two points, one of which has already been made in other words in previous
replies to this mail:

Invoking a resume key never stalls which makes possible or at least
facilitates a server returning a response to a request.

It is possible to build a general front end to an object that is not
trusted to be prompt. The frontended object is guaranteed to return,
perhaps with a response indicating that the original is taking too long and
that any subsequent response from the original will be discarded. The front
end transforms any object into one that may be trusted to be prompt.

The no-call bit of the segment key is to protect oneself from segment
keepers that do not return from a fault produced by accessing an invalid
portion of the segment.
Norman Hardy  <http://www.mediacity.com/~norm>