diff options
author | Rob Landley <rob@landley.net> | 2006-02-12 00:45:39 +0000 |
---|---|---|
committer | Rob Landley <rob@landley.net> | 2006-02-12 00:45:39 +0000 |
commit | c29a0f371a8b5409f79e88f26d00c7d9fc2caa4f (patch) | |
tree | 2fff7e8094b6878dd88a5579991269f8ef8b863b /docs/busybox.net | |
parent | 4926d643ea9ad56fc6b2173c9a3ce3719d6bb39f (diff) | |
download | busybox-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.html | 34 |
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 | |||
298 | that it's a big red flag warning "there be dragons here" rather than | 299 | that it's a big red flag warning "there be dragons here" rather than |
299 | something subtle and thus even more dangerous.)</p> | 300 | something 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 | ||
305 | check that all the data we asked for got read or written. Is this a real | ||
306 | world 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 | ||
311 | in real time but blocks until its entire input buffer (generally a couple | ||
312 | kilobytes) is read, then displays it all at once. In that case, we _want_ | ||
313 | the short read, for user interface reasons. (Note that read() should never | ||
314 | return 0 unless it has hit the end of input, and an attempt to write 0 | ||
315 | bytes should be ignored by the OS.)</p> | ||
316 | |||
317 | <p>As for short writes, play around with two processes piping data to each | ||
318 | other on the command line (cat bigfile | gzip > out.gz) and suspend and | ||
319 | resume a few times (ctrl-z to suspend, "fg" to resume). The writer can | ||
320 | experience short writes, which are especially dangerous because if you don't | ||
321 | notice them you'll discard data. They can also happen when a system is under | ||
322 | load and a fast process is piping to a slower one. (Such as an xterm waiting | ||
323 | on x11 when the scheduler decides X is being a CPU hog with all that | ||
324 | text console scrolling...)</p> | ||
325 | |||
326 | <p>So will data always be read from the far end of a pipe at the | ||
327 | same chunk sizes it was written in? Nope. Don't rely on that. For one | ||
328 | counterexample, see <a href="http://www.faqs.org/rfcs/rfc896.html">rfc 896</p> | ||
329 | for Nagle's algorithm</a>, which waits a fraction of a second or so before | ||
330 | sending out small amounts of data through a TCP/IP connection in case more | ||
331 | data comes in that can be merged into the same packet. (In case you were | ||
332 | wondering why action games that use TCP/IP set TCP_NODELAY to lower the latency | ||
333 | on their their sockets, now you know.)</p> | ||
334 | |||
301 | <br> | 335 | <br> |
302 | <br> | 336 | <br> |
303 | <br> | 337 | <br> |