Messages in this thread | | | Date | Sun, 28 Jun 1998 11:35:31 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
MOLNAR Ingo writes: > > On Sun, 28 Jun 1998, Richard Gooch wrote: > > > - old kernel and glibc 2.latest will not have scalable aio_*() [...] > > again, it's up to _us_ how well it scales. Look into glibc's sources. It > does something quite similar to your scheme. _If_ this glibc > implementation does not scale well, make it better. You are referring to > it as if the current implementation was something cast in stone ... > > old kernels and other systems do not scale in many ways, i do not see your > problem is ...
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
| |