Simon Kirby wrote:
> > While an 'edge-trigger' design is indeed simpler, I feel that it
> > ends up making the job of the application harder. A simple example
> > to illustrate the point: what if the application does not choose
> > to read all the data from an incoming packet? The app now has to
> > implement its own state mechanism to remember that there may be pending
> > data in the buffer, since it will not get another event notification
> > unless another packet arrives.
>
> What applications would do better by postponing some of the reading?
> I can't think of any reason off the top of my head why an application
> wouldn't want to read everything it can.
Pipelined server.
1. Wait for event.
2. Read block
3. If EAGAIN, goto 1.
4. If next request in block is incomplete, goto 2.
5. Process next request in block.
6. Write response.
7. If EAGAIN, wait until output is ready for writing then goto 6.
8. Goto 1 or 2, your choice.
(Here I'd go to 2 if the last read was complete -- it avoids a
redundant call to poll()).
If you simply read everything you can at step 2, you'll run out of
memory the moment someone sends you 100000 requests.
This doesn't happen if you leave unread data in kernel space --
TCP windows and all that.
enjoy,
-- Jamie
-
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