LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

Various wording cleanups

This commit is contained in:
Michael Kerrisk 2008-04-18 07:40:33 +00:00
parent 2737254c0a
commit 7cbaba9031
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
man2/select_tut.2
View File

@ -131,7 +131,7 @@ its file descriptors.
After
.BR select ()
has returned, \fIreadfds\fP will be
cleared of all file descriptors except for those file descriptors that
cleared of all file descriptors except for those that
are immediately available for reading with a
.BR recv (2)
(for sockets) or
@ -144,7 +144,7 @@ its file descriptors.
After
.BR select ()
has returned, \fIwritefds\fP will be
cleared of all file descriptors except for those file descriptors that
cleared of all file descriptors except for those that
are immediately available for writing with a
.BR send (2)
(for sockets) or
@ -169,7 +169,7 @@ After
.BR select ()
has returned,
\fIexceptfds\fP will be cleared of all file descriptors except for those
descriptors that are available for reading OOB data.
that are available for reading OOB data.
You can only ever
read one byte of OOB data though (which is done with
.BR recv (2)),
@ -192,7 +192,7 @@ them, then increment this value by one, and then pass this as \fInfds\fP to
\fIutimeout\fP
This is the longest time
.BR select ()
must wait before returning, even
may wait before returning, even
if nothing interesting happened.
If this value is passed as NULL,
then
@ -406,7 +406,7 @@ and
.BR send (2)
do \fInot\fP necessarily read/write the full amount of data
that you have requested.
If they do read/write the full amount, its
If they do read/write the full amount, it's
because you have a low traffic load and a fast stream.
This is not
always going to be the case.
@ -414,7 +414,7 @@ You should cope with the case of your
functions only managing to send or receive a single byte.
.TP
6.
Never read/write only in single bytes at a time unless your are really
Never read/write only in single bytes at a time unless you are really
sure that you have a small amount of data to process.
It is extremely
inefficient not to read/write as much data as you can buffer each time.
@ -438,7 +438,7 @@ or with
set to \fBEAGAIN\fP (\fBEWOULDBLOCK\fP).
These results must be properly managed (not done properly
above).
If your program is not going to receive any signals then
If your program is not going to receive any signals, then
it is unlikely you will get \fBEINTR\fP.
If your program does not
set non-blocking I/O, you will not get \fBEAGAIN\fP.
@ -838,8 +838,8 @@ you might suspect.
Another idea is to set non-blocking I/O using an
.BR ioctl (2)
call.
This also has its problems because you end up having
to have inefficient timeouts.
This also has its problems because you end up using
inefficient timeouts.
The program does not handle more than one simultaneous connection at a
time, although it could easily be extended to do this with a linked list