Messages in this thread | | | Date | Mon, 22 Jun 1998 23:17:02 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Thread implementations... |
| |
On Mon, 22 Jun 1998, Richard Gooch wrote:
> 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
| |