![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 1.5.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman|
Return to 1.5.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman |
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.