Messages in this thread | | | Date | Mon, 22 Jun 1998 23:41:42 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Thread implementations... |
| |
On Tue, 23 Jun 1998, Richard Gooch wrote:
> ext2? You mean regular files?
Yeah.
> > > 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.
You know it just occured to me that some time back I stopped advocating the NT method -- and by extension the VMS method... but I wasn't too clear on describing my current method maybe. NT/VMS actually do completion -- for example, if you do a write() you're told when it completes. That I think is way too expensive... I'm totally with you on the bloatness of that.
What I'm advocating now is something akin to select()/poll(), and I've been wrong to be calling it "completion ports". It's more like a "ready queue" -- a queue of FDs which are ready for read or write. You do a write() the kernel says EWOULDBLOCK, so you stop writing and you put that "thread" to sleep (you note that it's waiting for the FD to become ready for write). Sometime later the kernel tells you its ready for write() by sending the FD down the ready queue.
That seems like a fairly light kernel change (and I think the stuff may be in POSIX already -- rt signals and aio? I need to get a copy of the POSIX docs some day!). If you need true completion ports you can implement the rest of them at user-level.
> I still think that you can get as good performance with a few threads > and simple FD migration, though.
Yeah I need to investigate this anyhow -- because I still need to support other unixes. So it's probably the first approach that would be good once me (or someone else) gets into optimizing NSPR.
Dean
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |