|
|
1.1 ! root 1: .\" Copyright (c) 1983 Regents of the University of California. ! 2: .\" All rights reserved. The Berkeley software License Agreement ! 3: .\" specifies the terms and conditions for redistribution. ! 4: .\" ! 5: .\" @(#)1.5.t 6.3 (Berkeley) 5/12/86 ! 6: .\" ! 7: .sh Descriptors ! 8: .PP ! 9: .NH 3 ! 10: The reference table ! 11: .PP ! 12: Each process has access to resources through ! 13: \fIdescriptors\fP. Each descriptor is a handle allowing ! 14: the process to reference objects such as files, devices ! 15: and communications links. ! 16: .PP ! 17: Rather than allowing processes direct access to descriptors, the system ! 18: introduces a level of indirection, so that descriptors may be shared ! 19: between processes. Each process has a \fIdescriptor reference table\fP, ! 20: containing pointers to the actual descriptors. The descriptors ! 21: themselves thus have multiple references, and are reference counted by the ! 22: system. ! 23: .PP ! 24: Each process has a fixed size descriptor reference table, where ! 25: the size is returned by the \fIgetdtablesize\fP call: ! 26: .DS ! 27: nds = getdtablesize(); ! 28: result int nds; ! 29: .DE ! 30: and guaranteed to be at least 20. The entries in the descriptor reference ! 31: table are referred to by small integers; for example if there ! 32: are 20 slots they are numbered 0 to 19. ! 33: .NH 3 ! 34: Descriptor properties ! 35: .PP ! 36: Each descriptor has a logical set of properties maintained ! 37: by the system and defined by its \fItype\fP. ! 38: Each type supports a set of operations; ! 39: some operations, such as reading and writing, are common to several ! 40: abstractions, while others are unique. ! 41: The generic operations applying to many of these types are described ! 42: in section 2.1. Naming contexts, files and directories are described in ! 43: section 2.2. Section 2.3 describes communications domains and sockets. ! 44: Terminals and (structured and unstructured) devices are described ! 45: in section 2.4. ! 46: .NH 3 ! 47: Managing descriptor references ! 48: .PP ! 49: A duplicate of a descriptor reference may be made by doing ! 50: .DS ! 51: new = dup(old); ! 52: result int new; int old; ! 53: .DE ! 54: returning a copy of descriptor reference \fIold\fP indistinguishable from ! 55: the original. The \fInew\fP chosen by the system will be the ! 56: smallest unused descriptor reference slot. ! 57: A copy of a descriptor reference may be made in a specific slot ! 58: by doing ! 59: .DS ! 60: dup2(old, new); ! 61: int old, new; ! 62: .DE ! 63: The \fIdup2\fP call causes the system to deallocate the descriptor reference ! 64: current occupying slot \fInew\fP, if any, replacing it with a reference ! 65: to the same descriptor as old. ! 66: This deallocation is also performed by: ! 67: .DS ! 68: close(old); ! 69: int old; ! 70: .DE ! 71: .NH 3 ! 72: Multiplexing requests ! 73: .PP ! 74: The system provides a ! 75: standard way to do ! 76: synchronous and asynchronous multiplexing of operations. ! 77: .PP ! 78: Synchronous multiplexing is performed by using the \fIselect\fP call ! 79: to examine the state of multiple descriptors simultaneously, ! 80: and to wait for state changes on those descriptors. ! 81: Sets of descriptors of interest are specified as bit masks, ! 82: as follows: ! 83: .DS ! 84: #include <sys/types.h> ! 85: ! 86: nds = select(nd, in, out, except, tvp); ! 87: result int nds; int nd; result fd_set *in, *out, *except; ! 88: struct timeval *tvp; ! 89: ! 90: FD_ZERO(&fdset); ! 91: FD_SET(fd, &fdset); ! 92: FD_CLR(fd, &fdset); ! 93: FD_ISSET(fd, &fdset); ! 94: int fs; fs_set fdset; ! 95: .DE ! 96: The \fIselect\fP call examines the descriptors ! 97: specified by the ! 98: sets \fIin\fP, \fIout\fP and \fIexcept\fP, replacing ! 99: the specified bit masks by the subsets that select true for input, ! 100: output, and exceptional conditions respectively (\fInd\fP ! 101: indicates the number of file descriptors specified by the bit masks). ! 102: If any descriptors meet the following criteria, ! 103: then the number of such descriptors is returned in \fInds\fP and the ! 104: bit masks are updated. ! 105: .if n .ds bu * ! 106: .if t .ds bu \(bu ! 107: .IP \*(bu ! 108: A descriptor selects for input if an input oriented operation ! 109: such as \fIread\fP or \fIreceive\fP is possible, or if a ! 110: connection request may be accepted (see section 2.3.1.4). ! 111: .IP \*(bu ! 112: A descriptor selects for output if an output oriented operation ! 113: such as \fIwrite\fP or \fIsend\fP is possible, or if an operation ! 114: that was ``in progress'', such as connection establishment, ! 115: has completed (see section 2.1.3). ! 116: .IP \*(bu ! 117: A descriptor selects for an exceptional condition if a condition ! 118: that would cause a SIGURG signal to be generated exists (see section 1.3.2), ! 119: or other device-specific events have occurred. ! 120: .LP ! 121: If none of the specified conditions is true, the operation ! 122: waits for one of the conditions to arise, ! 123: blocking at most the amount of time specified by \fItvp\fP. ! 124: If \fItvp\fP is given as 0, the \fIselect\fP waits indefinitely. ! 125: .PP ! 126: Options affecting I/O on a descriptor ! 127: may be read and set by the call: ! 128: .DS ! 129: ._d ! 130: dopt = fcntl(d, cmd, arg) ! 131: result int dopt; int d, cmd, arg; ! 132: ! 133: /* interesting values for cmd */ ! 134: #define F_SETFL 3 /* set descriptor options */ ! 135: #define F_GETFL 4 /* get descriptor options */ ! 136: #define F_SETOWN 5 /* set descriptor owner (pid/pgrp) */ ! 137: #define F_GETOWN 6 /* get descriptor owner (pid/pgrp) */ ! 138: .DE ! 139: The F_SETFL \fIcmd\fP may be used to set a descriptor in ! 140: non-blocking I/O mode and/or enable signaling when I/O is ! 141: possible. F_SETOWN may be used to specify a process or process ! 142: group to be signaled when using the latter mode of operation ! 143: or when urgent indications arise. ! 144: .PP ! 145: Operations on non-blocking descriptors will ! 146: either complete immediately, ! 147: note an error EWOULDBLOCK, ! 148: partially complete an input or output operation returning a partial count, ! 149: or return an error EINPROGRESS noting that the requested operation is ! 150: in progress. ! 151: A descriptor which has signalling enabled will cause the specified process ! 152: and/or process group ! 153: be signaled, with a SIGIO for input, output, or in-progress ! 154: operation complete, or ! 155: a SIGURG for exceptional conditions. ! 156: .PP ! 157: For example, when writing to a terminal ! 158: using non-blocking output, ! 159: the system will accept only as much data as there is buffer space for ! 160: and return; when making a connection on a \fIsocket\fP, the operation may ! 161: return indicating that the connection establishment is ``in progress''. ! 162: The \fIselect\fP facility can be used to determine when further ! 163: output is possible on the terminal, or when the connection establishment ! 164: attempt is complete. ! 165: .NH 3 ! 166: Descriptor wrapping.\(dg ! 167: .PP ! 168: .FS ! 169: \(dg The facilities described in this section are not included ! 170: in 4.3BSD. ! 171: .FE ! 172: A user process may build descriptors of a specified type by ! 173: \fIwrapping\fP a communications channel with a system supplied protocol ! 174: translator: ! 175: .DS ! 176: new = wrap(old, proto) ! 177: result int new; int old; struct dprop *proto; ! 178: .DE ! 179: Operations on the descriptor \fIold\fP are then translated by the ! 180: system provided protocol translator into requests on the underlying ! 181: object \fIold\fP in a way defined by the protocol. ! 182: The protocols supported by the kernel may vary from system to system ! 183: and are described in the programmers manual. ! 184: .PP ! 185: Protocols may be based on communications multiplexing or a rights-passing ! 186: style of handling multiple requests made on the same object. For instance, ! 187: a protocol for implementing a file abstraction may or may not include ! 188: locally generated ``read-ahead'' requests. A protocol that provides for ! 189: read-ahead may provide higher performance but have a more difficult ! 190: implementation. ! 191: .PP ! 192: Another example is the terminal driving facilities. Normally a terminal ! 193: is associated with a communications line, and the terminal type ! 194: and standard terminal access protocol are wrapped around a synchronous ! 195: communications line and given to the user. If a virtual terminal ! 196: is required, the terminal driver can be wrapped around a communications ! 197: link, the other end of which is held by a virtual terminal protocol ! 198: interpreter.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.