Messages in this thread |  | | Date | Thu, 23 Jan 1997 09:31:38 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Good point of Linux over Windows NT |
| |
On Wed, 22 Jan 1997, Mark H. Wood wrote:
> On Mon, 20 Jan 1997, yuri mironoff wrote: > > > > On Sun, 19 Jan 1997, Greg Alexander wrote: > > > > > On Sun, 19 Jan 1997, yuri mironoff wrote: > > > [SNIPPED] > > Since the guts of NT are basically VMS warmed over (hmmm, that would make > it RSX11M mk III), "asynchronous I/O" probably means the ability to > request that the kernel start an I/O and send a signal when it is > complete. Meanwhile the user process goes on doing other stuff. > Traditionally Unix-like systems do this by forking. Linux can do better > than that, with threads. (VMS I/O forking is a special case of > multithreading.) So probably the only thing that is missing is some > syntactic sugar to package the I/O thread(s) conveniently. > > Did I get it right?
Well not quite. Both VAX/VMS and NT have the capability of making the kernel CALL a procedure that already exists in the user's working-set.
For instance, under VMS, you can actually execute programs. These programs are loaded into your process space and CALLED. The program that actually do this are SYS$SYSTEM:RUN.EXE and SYS$SYSTEM:RUNDET.EXE. One runs the program in your process context and the other runs it "detached" like fork(). Around version 6.0, RUN.EXE went away because DCL.EXE, the command interpreter can certainly "run" something which simply means allocate some memory, load the file into memory, and CALL its entry point.
Now an AST (Asynchronous System Trap) can CALL any procedure that you want. That procedure can also queue another AST. The AST occurs when something you set up happens. You can queue a request for some I/O. The sys$qiow routine allows one to wait (like recv() on a blocking socket) or sys$qio (no wait, nothing like this in Unix). In this case, the caller queues some I/O, control returns immediately to the user. The user can do other things... when the queued I/O data are ready, the system calls the AST routine with an AST parameter if specified.
Under Unix, one can set up a signal handler to handle SIGIO, however this is only executed if the caller set up a blocking socket or fd. NT and VAX/VMS work as though you had a non-blocking socket, you set up a signal handler to get called from a SIGIO signal, and the signal would happen EVEN IF you were not waiting for any I/O!!
Also, you are limited in what you can do with signal handler. Not so for an AST. You are not on a "signal stack". Although 'C' won't let you do this, the AST routine can be a location in main line code! Like jumping to a label. You never have to "return".
Cheers, Dick Johnson -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard B. Johnson Project Engineer Analogic Corporation Voice : (508) 977-3000 ext. 3754 Fax : (508) 532-6097 Modem : (508) 977-6870 Ftp : ftp@boneserver.analogic.com Email : rjohnson@analogic.com, johnson@analogic.com Penguin : Linux version 2.1.21 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  |