You currently can't poll for when a regular file delivers the block of
data you asked for. I'm not aware of any UNIX that supports this.
This is a whole new can of worms than the implementation of completion
ports/whatever.
> 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 exactly do you mean "you're told when it completes"?
> 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.
Earlier last year when you described completion ports, you suggested
that the queue for the completion events could just be a simple FD, so
I've assumed that's what you meant.
How is this different from "completion ports" in NT/VMS? It looks to
me these "event queues" are much the same as "completion ports", based
on the (vague) descriptions.
> 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.
When people have talked about implementing AIO in Linux, they had in
mind a userspace library which used threads to do the work. Each AIO
request is given a thread. I think part of the reason for such an
implementation is that you can't poll a regular file, so you need a
blocking thread. The other reason is why do it in the kernel if we can
develop a good userspace solution?
> > 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.
Or you could use my library...
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu