lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread implementations...
Dean Gaudet writes:
>
>
> On Tue, 23 Jun 1998, Richard Gooch wrote:
>
> > Richard Gooch writes:
> > > Can these NT completion ports multiple events from multiple FDs?
> >
> > Make that: "Can these NT completion ports multiplex events from
> > multiple FDs?"
>
> Yes.
>
> A typical method of using them is to maintain a homogenous pool of worker
> threads. Each worker thread can pick up a completed I/O, do further
> processing on the request, and "suspend" the request when it next needs to
> do I/O, and loop back to pick up some other completed I/O. To get an
> event on the port you have to start an I/O and the kernel then registers
> when the I/O has completed.
>
> This is different from select/poll event processing. In this case the
> events that the kernel delivers are of the form "if you read/write this FD
> right now, it won't block". To get an event to occur you first try to
> read/write and get EWOULDBLOCK and then you ask the kernel to tell you
> when it wouldn't block.
>
> Your proposal puts an event structure onto each FD, which the low level
> driver updates to indicate read/write readiness. I'm advocating taking
> that one step further and plop that readiness event onto a readiness
> queue. In this way you can completely avoid the select/poll and all the
> associated overhead -- instead you get a stream of "readiness" events from
> the kernel.

Sorry, I still don't see the difference between your completion ports
and event queues. In both cases, as far as I can tell, when I/O
completes a "message" is sent to some place. The application can then
pick off these events. Part of the message includes the FD which had
the completed I/O.

> Note that with sockets/pipes there is a read and write buffer, and it's
> obvious how the above works for them (readiness indicates a
> non-empty/non-full buffer as appropriate).
>
> It's somewhat less critical for non-sockets, but something similar is
> possible. Readiness for read means that a readahead completed... when the
> app finally read()s the buffer may or may not be present -- if it isn't
> present then return EWOULDBLOCK. For write, "readiness for write" means
> that there is buffer space to take at least one page of data. And if the
> app takes too long to issue the write(), return EWOULDBLOCK. i.e. just
> pretend there is a read and write buffer... there is one, it's all the
> buffer memory.

The last time I tried non-blocking I/O on a regular file, it still
blocked :-( This was with Linux 2.1.x.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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