summaryrefslogtreecommitdiff
path: root/docs/busybox.net
diff options
context:
space:
mode:
authorRob Landley <rob@landley.net>2006-02-12 00:45:39 +0000
committerRob Landley <rob@landley.net>2006-02-12 00:45:39 +0000
commitc29a0f371a8b5409f79e88f26d00c7d9fc2caa4f (patch)
tree2fff7e8094b6878dd88a5579991269f8ef8b863b /docs/busybox.net
parent4926d643ea9ad56fc6b2173c9a3ce3719d6bb39f (diff)
downloadbusybox-w32-c29a0f371a8b5409f79e88f26d00c7d9fc2caa4f.tar.gz
busybox-w32-c29a0f371a8b5409f79e88f26d00c7d9fc2caa4f.tar.bz2
busybox-w32-c29a0f371a8b5409f79e88f26d00c7d9fc2caa4f.zip
More random documentation.
Diffstat (limited to 'docs/busybox.net')
-rw-r--r--docs/busybox.net/programming.html34
1 files changed, 34 insertions, 0 deletions
diff --git a/docs/busybox.net/programming.html b/docs/busybox.net/programming.html
index 6dbe6931f..99fdaacb7 100644
--- a/docs/busybox.net/programming.html
+++ b/docs/busybox.net/programming.html
@@ -16,6 +16,7 @@
16 <ul> 16 <ul>
17 <li><a href="#tips_encrypted_passwords">Encrypted Passwords</a></li> 17 <li><a href="#tips_encrypted_passwords">Encrypted Passwords</a></li>
18 <li><a href="#tips_vfork">Fork and vfork</a></li> 18 <li><a href="#tips_vfork">Fork and vfork</a></li>
19 <li><a href="#tips_short_read">Short reads and writes</a></li>
19 </ul> 20 </ul>
20</ul> 21</ul>
21 22
@@ -298,6 +299,39 @@ each other while traversing the free memory lists). The thing about vfork is
298that it's a big red flag warning "there be dragons here" rather than 299that it's a big red flag warning "there be dragons here" rather than
299something subtle and thus even more dangerous.)</p> 300something subtle and thus even more dangerous.)</p>
300 301
302<h2><a name="tips_sort_read">Short reads and writes</a></h2>
303
304<p>Busybox has special functions, bb_full_read() and bb_full_write(), to
305check that all the data we asked for got read or written. Is this a real
306world consideration? Try the following:</p>
307
308<pre>while true; do echo hello; sleep 1; done | tee out.txt</pre>
309
310<p>If tee is implemented with bb_full_read(), tee doesn't display output
311in real time but blocks until its entire input buffer (generally a couple
312kilobytes) is read, then displays it all at once. In that case, we _want_
313the short read, for user interface reasons. (Note that read() should never
314return 0 unless it has hit the end of input, and an attempt to write 0
315bytes should be ignored by the OS.)</p>
316
317<p>As for short writes, play around with two processes piping data to each
318other on the command line (cat bigfile | gzip > out.gz) and suspend and
319resume a few times (ctrl-z to suspend, "fg" to resume). The writer can
320experience short writes, which are especially dangerous because if you don't
321notice them you'll discard data. They can also happen when a system is under
322load and a fast process is piping to a slower one. (Such as an xterm waiting
323on x11 when the scheduler decides X is being a CPU hog with all that
324text console scrolling...)</p>
325
326<p>So will data always be read from the far end of a pipe at the
327same chunk sizes it was written in? Nope. Don't rely on that. For one
328counterexample, see <a href="http://www.faqs.org/rfcs/rfc896.html">rfc 896</p>
329for Nagle's algorithm</a>, which waits a fraction of a second or so before
330sending out small amounts of data through a TCP/IP connection in case more
331data comes in that can be merged into the same packet. (In case you were
332wondering why action games that use TCP/IP set TCP_NODELAY to lower the latency
333on their their sockets, now you know.)</p>
334
301<br> 335<br>
302<br> 336<br>
303<br> 337<br>