lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

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