diff options
| author | Michael Kerrisk <mtk.manpages@gmail.com> | 2008-04-18 07:40:33 +0000 |
|---|---|---|
| committer | Michael Kerrisk <mtk.manpages@gmail.com> | 2008-04-18 07:40:33 +0000 |
| commit | 7cbaba9031be1f90f88a3445fade17bed23c4dd6 (patch) | |
| tree | f557afc1e6bda0f03ebd7665bd08e0993ded9f64 /man2/select_tut.2 | |
| parent | 2737254c0a3d6e44429fd77166dadb420a6400cf (diff) | |
| download | man-pages-7cbaba9031be1f90f88a3445fade17bed23c4dd6.tar.gz | |
Various wording cleanups
Diffstat (limited to 'man2/select_tut.2')
| -rw-r--r-- | man2/select_tut.2 | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/man2/select_tut.2 b/man2/select_tut.2 index b33323c7dc..2a97c5ea71 100644 --- a/man2/select_tut.2 +++ b/man2/select_tut.2 @@ -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 |