Ah, OK, you're referring explicitely to aio_*(), right?
> > 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).
Can these NT completion ports multiple events from multiple FDs?
> > 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.
We have that now with non-blocking I/O. I still don't understand the
model you are proposing.
> > 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.
So you want AIO in the kernel. That is even more bloatware than
"completion ports", "event queues" or whatever you're calling
them. From what I've seen on this list in the past, a kernel-space AIO
implementation is not favoured.
If you think that a userpace implementation is going to be too slow,
you have to show evidence of that.
> > Or you could use my library...
>
> I believe you said in a previous post that you don't care about NT.
I don't care about it in the context of a solution for a UNIX
system. If there is an NT solution, but it doesn't exist in UNIX, then
it doesn't help me, or others who want to get the best out of their
UNIX systems.
> 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
Karma has been ported to:
VXMVX
alpha_OSF1
c2_ConvexOS
crayPVP_UNICOS
hp9000_HPUX
i386_Linux
i386_Solaris
mips1_IRIX5
mips1_ULTRIX
mips2_IRIX5
mips2_IRIX6
mips4_IRIX6
rs6000_AIX
sparc_Solaris
sparc_SunOS
and code that doesn't care about CPU type (i.e. most of it) will also
compile on a "generic" POSIX machine.
plus I'll be distributing a small tarball which contains just the
stuff needed to compile the FD management package, so it can be
included in a separate package/library.
> ported to 20 unixes, plus WIN32, and has ports underway for pretty much
> everything else of interest.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu