[lkml]   [1997]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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:
    > > >
    > 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

    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".

    Dick Johnson
    Richard B. Johnson
    Project Engineer
    Analogic Corporation
    Voice : (508) 977-3000 ext. 3754
    Fax : (508) 532-6097
    Modem : (508) 977-6870
    Ftp :
    Email :,
    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.

     \ /
      Last update: 2005-03-22 13:38    [W:0.022 / U:10.352 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site