Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!vsi1!daver!lynx!m5
From: m5@lynx.uucp (Mike McNally)
Newsgroups: comp.unix.wizards
Subject: Re: Asynchronous I/O under UNIX
Message-ID: <6679@lynx.UUCP>
Date: 19 Dec 89 16:22:12 GMT
References: <932@crash.cts.com>
Organization: Lynx Real-Time Systems, Inc., Campbell CA
Lines: 26

peterson@crash.cts.com (John Peterson) writes:

>   My collegues and I have worked out a rough sketch of a way of doing
>asynchronous I/O. One would fork off a copy of your process, the child
>would 'nap' until an I/O request came from the parent. Upon receipt of
>an I/O request, the child goes off and issues a synchronous I/O request
>like one ordinarily does, and then set a flag of some sort when the I/O
>has completed. The data to be moved would be stored in memory accessible
>to the parent and child processes, probably using System V shared memory.

Sounds OK to me, if you're willing to swallow the cost of starting a
new process for each I/O transaction.  Of course, when the world gets
"threads" or "lightweight tasks" or whatever the current buzzword is,
this gets much cheaper; in fact, if I had threads, I don't think I'd
want or need a separate kernel-supported async I/O mechanism.






-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.