Editing DNIX (section)

== Handlers ==
Under DNIX, a process could be used to handle I/O requests and to extend the file system. Such a process was called a ''Handler'', and was a major feature of the operating system. A handler was defined as a process that owned at least one ''request queue'', a special file descriptor that was procured in one of two ways: with a <code>F_ORQ</code> or a <code>F_MOUNT</code> call. The former invented an isolated request queue, one end of which was then typically handed down to a child process. (The network remote execution programs, of which there were many, used this method to provide standard I/O paths to their children.)  The latter hooked into the file system so that file I/O requests could be adopted by handlers. (The network login programs, of which there were even more, used this method to provide standard I/O paths to their children, as the semantics of logging in under Unix requires a way for multiple perhaps-unrelated processes to horn in on the standard I/O path to the operator.)  Once mounted on a directory in the file system, the handler then received all I/O calls to that point.

A handler would then read small kernel-assigned request data structures from the request queue. (Such reading could be done synchronously or asynchronously as the handler's author desired.)  The handler would then do whatever each request required to be satisfied, often using the DNIX <code>F_UREAD</code> and <code>F_UWRITE</code> calls to read and write into the request's data space, and then would terminate the request appropriately using <code>F_TERMIN</code>. A privileged handler could adopt the permissions of its client for individual requests to subordinate handlers (such as the file system) via the <code>F_T1REQ</code> call, so it didn't need to reproduce the subordinate's permission scheme. If a handler was unable to complete a request alone, the <code>F_PASSRQ</code> function could be used to pass I/O requests from one handler to another. A handler could perform part of the work requested before passing the rest on to another handler. It was very common for a handler to be state-machine oriented so that requests it was fielding from a client were all done asynchronously. This allowed for a single handler to field requests from multiple clients simultaneously without them blocking each other unnecessarily. Part of the request structure was the process ID and its priority so that a handler could choose what to work on first based upon this information, there was no requirement that work be performed in the order it was requested. To aid in this, it was possible to poll both request and trap queues to see if there was more work to be considered before buckling down to actually do it.

<syntaxhighlight lang="c">
struct ireq {                   /* Structure of incoming request */
        short   ir_fc;          /* Function code */
        short   ir_rn;          /* Request number */
        long    ir_opid;        /* Owner ID that you gave on open or mount */
        long    ir_bc;          /* Byte count */
        long    ir_upar;        /* User parameter */
        long    ir_rad;         /* Random address */
        ushort  ir_uid;         /* User ID */
        ushort  ir_gid;         /* User group */
        time_t  ir_time;        /* Request time */
        ulong   ir_nph;
        ulong   ir_npl;         /* Node and process ID */
};
</syntaxhighlight>

There was no particular restriction on the number of request queues a process could have. This was used to provide networking facilities to [[chroot]] jails, for example.

=== Examples ===
{{Redirect|DNET|the brain tumor|Dysembryoplastic neuroepithelial tumour}}
To give some appreciation of the utility of handlers, at ISC handlers existed for:
* foreign file systems
** [[File Allocation Table|FAT]]
** [[CD-ROM]]/[[ISO9660]]
** disk image files
** RAM disk (for use with write-protected boot disks)
* networking protocols
** [[DNET]] (essentially [[X.25]] over [[Ethernet]], with [[multicast]] capability)
** [[X.25]]
** [[TCP/IP]]
** [[Digital Equipment Corporation|DEC]] [[Local Area Transport|LAT]]
** [[AppleTalk]]
* remote file systems
** [[DNET]]'s /net/machine/path/from/its/root...
** [[Network File System (protocol)|NFS]]
* remote login
** ncu ([[DNET]])
** [[telnet]]
** [[rlogin]]
** wcu ([[DNET]] GUI)
** [[X.25]] [[Packet Assembler/Disassembler|PAD]]
** [[Digital Equipment Corporation|DEC]] [[Local Area Transport|LAT]]
* remote execution
** rx ([[DNET]])
** remsh
** rexec
* system extension
** windowman (GUI)
** vterm ([[xterm]]-like)
** document (passbook) printer
** dmap (ruptime analog)
** windowmac (GUI gateway to Macintosh)
* system patches
** named pipe handler