lkml.org 
[lkml]   [1997]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Good point of Linux over Windows NT
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans