Hacker News new | past | comments | ask | show | jobs | submit login

AKA "some complicated buffering scheme". Without blocking IO you have to buffer the output locally.



Or just stop processing....

You're picking nits frankly. The system can be useful. But it does deadlock and/or cause delays if your output program stops reading from the pipe temporarily or permanently. The deadlocked secondprogram was just a simple example of when this happens.

This sort of behavior is a rare case. It is far from rare though in a less degenerate form. In the very simple case of displaying text on the command line you will fill your output buffer all the time, but with the flushes, you'll vastly slow the program down to the speed of text display in your terminal as you make all text output every time, as opposed to just when the buffer display program runs.

Which do you think will run faster: Cat without those flushes or cat with those flushes?

This technique is not universally applicable, as the article says. It does not fit all cases. It has costs.

It does also have applications. But it's not the suggested universal technique.


Sigh.

And the difference between "stop processing" and letting the IO block is what?


You can do other things....like say, print out on stderr that there is a problem after a certain timeout, email technical support, or restart the second program.

If you use blocking IO, you just silently fail.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: