🚀 go-pugleaf

>Are there reasons for using fork() other than ones having to do with certian
>limitations of UNIX, such as lack of asynchronious I/O and process creation
>parameters to functions like execv() et. al. (things like priority and I/O
>binding)?

The UNIX system is somewhat of a dinosaur in some respects. There are some
implementations of asynchronous I/O in the form of pipes and sockets and
message queues, but all of these require a server process to stick around
and listen on the particular data structure. I should further add that normal
UNIX I/O is not guaranteed to be synchronous, but only appears to be
synchronous to the calling process. When another process becomes involved
semaphores are required for synchronization. To some extent the same is true
of OS9.

> I am curious to know whether there really is any reason for trying
>to implement a UNIX-style fork() in an O/S like OS-9/68K or CDOS-68K. That
>is if the various non-fork() type subprocess creating functions had the
>nesscesary additional arguments and the I/O system provided some sort of
>user-accessable asynchronious I/O access, would a UNIX-style fork() still be
>neccessary or usefull for anything?

There have been other approaches to this. The most commonly used one is that
of systems like VAX/VMS and RSX-11M. In this case the structure of the I/O
system is very different. VMS uses an I/O architecture based on a single
type of system service called QIO. The QIO interface provides access to
a layered I/O system. To access a physical device using totally raw I/O,
we specify PHYSICAL in a parameter to QIO and pass it a data structure
containing an entrypoint specification and arguments to the device driver.
Support is provided for LOGICAL and VIRTUAL I/O as well. Logical I/O is
more akin to what we UNIX folks consider raw, but may also be applied to
mailboxes (message queues). Virtual I/O is the usual cooked I/O that we
use with files with the exception that it allows us the ability to use to
moded features on devices and files supporting i/o controls by invoking
the IO$SETMODE service via QIO.

QIO comes in a synchronous flavor (QIOW or QIO with wait) and an async.
flavor (just QIO). Unfortunatly, the I/O is still asynchronous when you
add more processes to the picture, so we are back to the same problem that
we have with UNIX and OS9. The effect of a call to QIO without wait is to
queue the i/o request and return, which always steals the process's context
but it DOESN'T put it in the wait queue. The is what I like about using it.
QIO greatly reduces system overhead in those situations where we don't care
whether i/o is sync. or async. (which is most times).

NOW for the fly (splat).
QIO has 9-countum-9 arguments in order to do all of this, yuck. The reason
for this is that since you can't get a real return status from the function,
you have to put the return data asynchronously into an i/o status block
and set an event flag to tell the process that the i/o completed. All of this
combined with the general purpose nature of QIO make for this inconvenience.

You may be asking yourself "What the hell does all of this have to do with
the structure and mechanism of fork()?" Well... under the same OS's there
is no fork(). They instead us a system service called CREPRC. This function
is very similar to the OS9 fork(). Existing input,output,error file
descriptors may be passed to the created process, but no others. In fact
no other portion of the parent process is actually shared with the child
and must be created anew for the new process. This greatly increases the
overhead of process creation. Once again (like QIO) the large number of
parameters passed to the function can be an inconvenience. Oh yes, it is
also SLOW.

OS9 makes a reasonably nice compromise. Fork() doesn't have so many parms.
that it is inconvenient and much of the parent process info is shared with the
child (like UNIX fork) and is fast (like UNIX fork).

I think that what we really need is a couple more kinds of entries to the
UNIX and OS9 I/O systems. Something that works like QIO without wait on
I/O calls could really speed things up. I should add in closing that UNIX
I/O calls ARE faster than the VMS counterparts because of the layered I/O
system under VMS. Just another application of Grosch's Law :-)


    Steve Blasingame (Oklahoma City)
    ihnp4!occrsh!gorgo!bsteve
    bsteve@eris.berkeley.edu