Messages in this thread | | | From | (Derek Fawcus) | Subject | Re: Good point of Linux over Windows NT | Date | Tue, 21 Jan 1997 08:38:41 +0100 (GMT) |
| |
David S. Miller wrote: > Kernel level support for async-IO is something that should be at least > thought about. From the UNIX's that I've heard actually do it, they > limit you to one outstanding async-IO request per task/thread. This > seems to suggest it is not a trivial problem to solve at all. > > From what I've heard NT allows numerous (unlimited?) outstanding > async-IO requests to be queued to the system, and programmers love > this. Can someone validate this? It's what I've heard, I want to > know if it is true.
I don't know about VMS, but a RT OS I use at work (FlexOS) allows this (although limited to 31 outstanding async-requests). From a programming point of view it is quite nice (esp. for state machines). I've been told in the past that this is similar to VMS.
I happen to know how this is implemented (in FlexOS), and to do the same way in Linux would probably be a major change - basically the FlexOS kernel treats all requests as async (sync being a special case using the 32nd request and having a builtin call to a wait_for_event_completion() fn).
At the kernel level (in kernel process's and device drivers) FlexOS allows a unlimited (bounded by available memory) number of async-IO requests. The 31 async + 1 sync requests at the process level is simply due to using a 32 bit mask in the API to identify the requests. If it used a select() style fdset, the obviously a larger number could be handled.
I rather suspect that Linux clone() threads could be used to implement similar capabilities (at the user level), simply requiring more thought from the programmer in their use.
DF -- Derek Fawcus df@eyrie.demon.co.uk
| |