Return to xindex.ms CVS log

Up to [Research Unix] / researchv10dc / vol2 / index / Junk

Annotation of researchv10dc/vol2/index/Junk/xindex.ms, revision 1.1

1.1     ! root        1: .so ../ADM/mac
        !             2: .Tm index
        !             3: .XX 48 667 "Index"
        !             4: .Tm index
        !             5: .TL
        !             6: Index
        !             7: .AU
        !             8: L. L. Cherry
        !             9: .2C
        !            10: .NH
        !            11: Introduction
        !            12: .PP
        !            13: The part of the
        !            14: .UX
        !            15: operating system that deals with terminals
        !            16: and other character devices
        !            17: has always been complicated.
        !            18: In recent versions of the system it has become even more so, for
        !            19: two reasons.
        !            20: .IP 1)
        !            21: Network connections require protocols more ornate than are
        !            22: easily accommodated in the existing structure.
        !            23: A notion of ``line disciplines'' was only partially successful,
        !            24: mostly because in the traditional system only one line discipline
        !            25: can be active at a time.
        !            26: .IP 2)
        !            27: The fundamental data structure of the traditional character I/O system,
        !            28: a queue of individual characters (the ``clist''),
        !            29: is costly because it accepts and dispenses characters one at a time.
        !            30: Attempts to avoid overhead by bypassing the mechanism entirely
        !            31: or by introducing
        !            32: .I "ad hoc
        !            33: routines succeeded in speeding up the
        !            34: code at the expense of regularity.
        !            35: .LP
        !            36: Patchwork solutions to specific problems were
        !            37: destroying the modularity of this part of the system.
        !            38: The time was ripe to redo the whole thing.
        !            39: This paper describes the new organization.
        !            40: .PP
        !            41: The system described here runs on about 20 machines
        !            42: in the Information Sciences Research Division of Bell Laboratories.
        !            43: Although it is being investigated by other parts of Bell Labs,
        !            44: it is not generally available.
        !            45: .Tm overview
        !            46: .NH
        !            47: Overview
        !            48: .PP
        !            49: This section summarizes the nomenclature, components, and mechanisms
        !            50: of the new I/O system.
        !            51: .NH 2
        !            52: .Tm streams
        !            53: .I "Streams
        !            54: .PP
        !            55: A
        !            56: .I "stream
        !            57: is a full-duplex connection between a user's process and a device
        !            58: or pseudo-device.
        !            59: It consists of several linearly connected processing modules,
        !            60: and is analogous to a Shell pipeline, except that
        !            61: data flows in both directions.
        !            62: The modules in a stream communicate almost exclusively
        !            63: by passing messages to their neighbors.
        !            64: Except for some conventional variables used for flow control, modules do not
        !            65: require access to the storage of their neighbors.
        !            66: Moreover, a module provides only one entry point to each neighbor, namely
        !            67: a routine that accepts messages.
        !            68: .PP
        !            69: At the end of the stream closest to the process
        !            70: is a set of routines that provide the interface to the rest of the system.
        !            71: A user's
        !            72: .I "write
        !            73: and
        !            74: I/O control requests are turned into messages sent to the stream,
        !            75: and
        !            76: .I "read
        !            77: requests take data from the stream and pass it to the user.
        !            78: At the other end of the stream is a 
        !            79: device driver module.
        !            80: Here, data arriving from the stream is sent to the device;
        !            81: characters and state transitions detected by the device are
        !            82: composed into messages and sent into the stream towards the user program.
        !            83: Intermediate modules process the messages in various ways.
        !            84: .PP
        !            85: The two end modules in a stream become connected automatically when
        !            86: the device is opened;
        !            87: intermediate modules are attached dynamically by request of the user's program.
        !            88: Stream processing modules are
        !            89: symmetrical; their read and write interfaces are identical.
        !            90: .NH 2
        !            91: .Tm queues
        !            92: .I "Queues
        !            93: .PP
        !            94: Each stream processing module consists of a pair of
        !            95: .Tm queues
        !            96: .I "queues,
        !            97: one for each direction.
        !            98: A queue comprises not only a data queue proper, but also two routines
        !            99: and some status information.
        !           100: One routine is the
        !           101: .I "put procedure,
        !           102: which is called by its neighbor
        !           103: to place messages on the data queue.
        !           104: The other, the
        !           105: .I "service procedure,
        !           106: is scheduled to execute whenever there is work for it to do.
        !           107: The status information includes a pointer to the next queue downstream,
        !           108: various flags, and a pointer to additional state information required
        !           109: by the instantiation of the queue.
        !           110: .Tm queues
        !           111: Queues are allocated in such a way that the routines associated with
        !           112: one half of a stream module may find the queue associated with the other half.
        !           113: (This is used, for example, in generating echos for terminal input.)
        !           114: .NH 2
        !           115: .Tm message blocks
        !           116: .I "Message blocks
        !           117: .Tm queues
        !           118: .PP
        !           119: The objects passed between queues are blocks obtained from an allocator.
        !           120: Each contains a
        !           121: .I "read pointer,
        !           122: a
        !           123: .I "write pointer,
        !           124: and a
        !           125: .I "limit pointer,
        !           126: which specify respectively the beginning of information being passed, its end,
        !           127: and a bound on the extent to which the write pointer may be increased.
        !           128: .PP
        !           129: The header of a block specifies its type; the most common blocks contain
        !           130: data.
        !           131: There are also control blocks of various kinds,
        !           132: all with the same form as data blocks and obtained from the same
        !           133: allocator.
        !           134: For example, there are control blocks to introduce delimiters
        !           135: into the data stream, to pass user I/O control requests, and to announce
        !           136: special conditions such as line break and carrier loss on terminal
        !           137: devices.
        !           138: .PP
        !           139: Although data blocks arrive in discrete units
        !           140: at the processing modules,
        !           141: boundaries between them are semantically insignificant;
        !           142: standard subroutines may try to coalesce adjacent
        !           143: data blocks in the same queue.
        !           144: Control blocks, however, are never coalesced.
        !           145: .NH 2
        !           146: .Tm scheduling
        !           147: .I "Scheduling
        !           148: .PP
        !           149: Although each queue module behaves in some ways like a separate process,
        !           150: it is not a real process; the system saves no state information
        !           151: for a queue module that is not running.
        !           152: In particular queue processing routines do not block when they cannot proceed,
        !           153: but must explicitly return control.
        !           154: A queue may be
        !           155: .I "enabled
        !           156: by mechanisms described below.
        !           157: When a queue becomes enabled, the system will, as soon as convenient,
        !           158: call its service procedure entry,
        !           159: which removes successive blocks
        !           160: from the associated data queue, processes them, and places them on the
        !           161: next queue by calling its put procedure.
        !           162: When there are no more blocks to process, or when the next queue becomes
        !           163: full, the service procedure returns to the system.
        !           164: Any special state information must be saved explicitly.
        !           165: .PP
        !           166: Standard routines make enabling of queue modules largely automatic.
        !           167: For example, the routine that puts a block on a queue
        !           168: enables the queue service routine if the queue was empty.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.