So, building an application using the aio_*() interface is not
sensible.
> If you want performance and have several options, the only reasonable
> thing to do is measure the performance to pick the valid option. [Once
> you have a reasonably accurate model, you can get away by looking at
> symbols instead of measuring...]
What symbols are you referring to?
> > Let me say it another way: I want a solution that will scale well on
> > any vanilla POSIX.4 system (i.e. installing glibc is not an option).
>
> Are you saying that you object to casting your solution in terms which
> are easily formed into aio_*()?
I want to present a lightweight interface that will scale as much as
possible for each OS (and I include NT). On UNIX systems, this will
probably be implemented with migrating FDs. On a system that supports
readiness queues, I would make use of that facility.
Making use of the aio_*() interface is a problem, though, because it
does not scale well (in general). If a particular implementation is
*known* to have scalable aio_*(), then it may make sense to use that
facility. However, the story on Linux is that aio_*() is not known to
be scalable. Even if kernel 2.latest has kernel support to make
aio_*() scalable, and glibc 2.latest uses this facility, this is of no
help. Why? Because of the following scenarios:
- old kernel and glibc 2.older will not have scalable aio_*()
- old kernel and glibc 2.latest will not have scalable aio_*(), and
may not even work properly (how does glibc know that the FD will be
passed to an RT signal handler?)
The aio_*() facilities for Linux would have to provide a mechanism to
be used at run-time to determine if the implementation is scalable or
not. Since I don't expect the Linux implementation to bother with that
(the expected response is "grab the latest glibc and kernel"), aio_*()
for Linux is a poor choice.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu