Messages in this thread | | | Date | Mon, 22 Jun 1998 17:53:31 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Dean Gaudet writes: > Note that the poll_ctrl you introduce in > > <ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.1/fastpoll-readme>
Hey! Someone's already read it:-)
> is almost all the work required for a completion queue. The additional > code required is to add "void *user_data; int completion_fd;" to the event > structure. If the low level code is smart enough to fill in your events > structure it's smart enough to plop a word into a pipe when necessary. So > are you sure it'd be too much bloat to do completion queues? :) > > On Mon, 22 Jun 1998, Richard Gooch wrote: > > > I've written a document that tries to cover the various issues with > > I/O events. Check out: > > http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
The new mechanism I introduce optimises an existing POSIX interface. Also, it is optional: drivers which continue to do things the old way will still work, they just won't be as fast. With completion ports all drivers will have to be modified, so it involves a lot more work.
I do agree that if my fastpoll optimisation is added, then the logical place to add completion port support is in poll_notify(). I've added a note in my documentation about that.
BTW: what happens when a FD is closed before the completion event is read by the application? Protecting against that could be tricky, and may require more code than simply dropping an int into a pipe.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |