On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
> Consider a program which reads from point A, writes to point B. If
> the buffer associated with B fills up, then we don't want to continue
> reading from A.
>
> A/B may be network sockets, pipes, or ptys.
Fine, but we can bind the event watching to the device or socket or pipe
that will clog up, right? In which case, we'll later get a write event
(just like with select()), and then once there is some progress you can
go back to read()ing from the original descriptor. This is even easier
than using select() because you don't have to take the descriptor out of
the read set and put it in the write set temporarily -- it will
automatically work that way.
> Or perhaps you receive a request to use a resource that is currently
> busy. Does your application want to postpone the request, or read the
> data immediately, even if the request can't be serviced yet?
Assuming this "resource" has a way of waking up the process when it
unclogs, then you can go back and read the remaining data later, which is
what you would want to do anyway.
> My point is that I can easily think of several examples as to where
> this behavior may be beneficial to the application, and I use some of
> them myself. You can indeed get the same result by forcing each and
> every application that wants this behavior to implement their own
> tracking mechanism, but this strikes me as error-prone and places an
> undue burden on the application programmer.
I can see that you could write it this way... I'm just trying to see if
it's really needed. :)
As I wrote in my last email to Jamie, you would need to implement a
tracking mechanism in any case to avoid DoS attacks from clients or a
case where a single client can clog up the reading from any other client.
And you'd need to take the descriptor out of the read() set in the
select() case anyway, so I don't really see what's different.
> You can find my paper at http://people.freebsd.org/~jlemon
I'll go and read it now. :)
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:16 EST