[coyotos-dev] Re-thinking FCRBs

[Valerio Bellizzomi]

On 20/02/2007, at 12.33, Jonathan S. Shapiro wrote:

>On Tue, 2007-02-20 at 15:23 +0100, Marcus Brinkmann wrote:
>> At Thu, 15 Feb 2007 14:15:19 -0500,
>> "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
>> > ** So what about asynchronous *sends* ??
>> > 
>> > If we need a mechanism for asynchronous completion, what about a
>> > mechanism for asynchronous sends?
>> > 
>> > My answer is "no". If the use of asynchronous receive is properly
>> > engineered, sends will not block. If they do you have a systemic
issue
>> > and my sense is that you want to see it rather than obscure it. I
could
>> > be completely wrong on this, and I'ld appreciate input on this point.
>> 
>> I have only come up with one use case for asynchronous send.  It's the
>> case where one does not want to allocate a stall queue in the server
>> for "blocking" RPCs like reading from an empty pipe (which is a
>> read-only operation and presumably should not allocate server
>> resources).  In principle, it is not clear why the server should need
>> to allocate a queue for such client operations, as there already is a
>> kernel queue that could be used for this purpose. However, pushing a
>> client back to a send() operation on an end point that the server is
>> not listening on (until the operation can potentially be completed)
>> makes send() a blocking operation.
>
>I'm confused, because there is no mechanism for a server to allocate a
>stall queue at all.
>
>In the read on empty pipe case, where server does not listen actively,
>sender will block.
>
>The motivation for asynchronous send in this case would be to allow the
>*sender* to avoid blocking, or to enqueue multiple operations.
>
>My feeling is: if the server is correctly implemented for its
>requirements this becomes a non-issue (because the server will arrange
>to be listening). If it is not, you have bigger problems than
>asynchronous send can solve for you.

If there are bigger problems probably you want to make them visible to
allow easier debugging.


val