This is not necessarily true. These "older" systems (and 2.1.107 for
that matter) should be able to be made to scale well with the right
userspace code.
> the only possible showstopper is some API bug in the aio_*() interface,
> which prevents a scalable implementation in theory. It is not an argument
> that the current implementation is not scalable, and this is what i was
> telling you from day 1 on ... it was just a humble suggestion to maybe
> integrate your concept into the existing aio_*() interface, but just
> forget about this suggestion, this is getting silly ...
Look, I have no problem with improving the glibc aio_*()
implementation so that it scales well. I think it should be done. It's
just that an application (or thin support library) should not depend
on using aio_*() since it isn't always scalable.
It would be OK if the Linux/glibc aio_*() implementation was *known*
to be scalable (at least for public releases of glibc and kernel 2.0.x
and 2.1.x). That way a support library could do #ifdef __linux__ and
use aio_*() with confidence. But will such a guarantee be made?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu