> 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.
As long as ext2 and sockets support it I'd be happy ;)
> 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.
I don't see a problem -- it's the application that interprets the meanings
of the ints coming off the pipe. If the app closes while it possibly
still has outstanding stuff then that's a bug in the app. There's no
problem for the kernel -- if the FD doesn't get re-used it'll return EBADF
when the app tries to use it... if it's re-used then the app gets whatever
damage it creates.
But suppose it was re-used. The data coming off the completion port means
only "ready for read" or "ready for write". The app is almost certainly
using non-blocking read/write, and when it attempts it'll get EWOULDBLOCK
if things weren't ready.
Although I suppose you could queue a special event on close... so that the
app could be sure that all events were flushed.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu