[coyotos-dev] Re-thinking FCRBs

[Jonathan S. Shapiro]

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.

shap

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100