[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kqueue microbenchmark results
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.

-- Jamie
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.288 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site