Re: [CapROS-devel] Proposed change to string passing
Status: Beta
Brought to you by:
clandau
From: Charles L. <cl...@ma...> - 2007-11-12 23:49:04
|
At 6:27 PM -0500 11/12/07, Jonathan S. Shapiro wrote: >On Mon, 2007-11-12 at 15:23 -0800, Charles Landau wrote: >> At 4:57 PM -0500 11/12/07, Jonathan S. Shapiro wrote: >> >1. There is no such thing as a prompt SEND. An EROS process performing a >> >SEND can be indefinitely blocked if receiver is unavailable. >> >> No, a SEND to a Resume key can be prompt. In my proposal, a prompt >> SEND never generates an IDC; the receiver must receive the string >> immediately. > >Yes. This is a flaw. It presumes (implicitly) that the higher-level >protocol is synchronous. You're introducing a new term "synchronous/asynchronous" into the discussion, whose meaning isn't clear to me in this context. After a SEND (including any string transmission), the sender and receiver are both running in parallel. This is not what I think of as synchronous. >This assumption does not seem necessary. If you're sending to a Resume key, the receiver was Waiting for the message, so it would seem to be necessarily a synchronous protocol. > > In a prompt SEND, the outgoing buffer can be safely retired in the >> instruction following the SEND. > >Not if the protocols are asynchronous. You are making assumptions about >the higher level protocol. See above. Prompt SEND implies you are invoking a Resume key, which implies the protocol is synchronous. > > >Therefore, this form of delivery can only be used when the sender is >> >willing to accept at least one of (1) denial of resource (via >> >non-reclaimable memory), (2) denial of control flow (via non-prompt >> >wait), or (3) unreliable delivery (because there is no way to know if >> >memory is being reclaimed prematurely). >> >> If by "this form of delivery" you mean a non-prompt SEND. > >Not what I meant. I meant any delivery involving an IDC. Only non-prompt deliveries involve an IDC, so (2) applies. |