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

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