Messages in this thread | | | Date | Wed, 24 Jun 1998 10:30:00 +1000 | From | Richard Gooch <> | Subject | Re: 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
| |