Messages in this thread | | | Date | Sun, 28 Jun 1998 11:07:38 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Raul Miller writes: > Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> wrote: > > Maybe my point is still being missed. Glibc is neither the solution, > > nor is its packaging of new solutions into standard interfaces of any > > relevance *when those interfaces are not explicitely scalable*. > > > > The aio_*() interface is not explicitely scalable. Since > > implementations are free to emulate using threads, aio_*() is not > > scalable across POSIX.4 systems. POSIX.4 says nothing about the cost > > (or reasonableness) of submitting thousands of aio_*() requests. That > > means it could be good or bad, depending on which OS you are using. > > So?
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
| |