Re: Thread implementations...

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 23 Jun 1998 16:07:19 +1000


Dean Gaudet writes:
>
>
> 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 ;)

ext2? You mean regular files?

> > 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.

What does NT do? If we're considering implementing something similar
to NT, it would be worth knowing what the NT policy is.

I still think that you can get as good performance with a few threads
and simple FD migration, though.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu