> 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.
This is just asynch i/o. I'd be surprised if any of the commercial unixes
lack it.
> What exactly do you mean "you're told when it completes"?
You write/read a buffer, and control returns immediately. Some
unspecified time later, when the write/read completes, your program is
informed either via a completion port (NT), or via a function you passed
to the kernel (VMS).
> 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.
Nope, completion ports are far heavier... they actually imply that some
I/O has completed. Whereas what I'm advocating only implies that some I/O
wouldn't block if tried.
> 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?
This is going in circles -- this is exactly the point I've been debating
-- whether this is "good" or not.
> Or you could use my library...
I believe you said in a previous post that you don't care about NT.
Unfortunately, I do. And I can't find anything on your pages about
portability... I'm assuming you're referring to karma. NSPR is already
ported to 20 unixes, plus WIN32, and has ports underway for pretty much
everything else of interest.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu