10 ms·
I'm not talking about no one receiving output. I'm talking about this case: You write a program called "thefirstprogram". Who cares what it does. However, a us
by gte910h 17y ago
I'm not talking about no one receiving output. I'm talking about this case:
You write a program called "thefirstprogram". Who cares what it does. However, a user is pushing its (standard) output into a second program called "asecondprogram". Now imagine "asecondprogram" has melted, but not terminated. It's basically in a screwed up state.
So the run command was:
bash-2.04> thefirstprogram | asecondprogram
I believe the flushing scheme advocated in the article is to be considered harmful, as you will in fact never see an error message if asecondprogram gets in a bad state and stops reading from stdin (and the buffers fill up).
I do agree the flushing makes for nicer ordering of error messages, but is more fragile.
Only used flushed output when you really need flushed output otherwise you'll get less resilience in the case of meltdown of cooperating programs.
- ars 17y agoWhat?! If the second program is messed up, it makes no difference if you flush or not. You'll still never see an error message. Stdin will fill up, flush or not, the program will block, and then sit there - no error message. You could maybe detect if stdin is blocked and say something on stderr - but if you want to do that it makes no difference whatsoever if you flush stdout or not.
- gte910h 17y agoNo, stderr isn't being piped with that command. So you will see it printed out on the command line. You have to explicitly pipe stderr as well if you don't want this behavior
- ars 17y agoYou don't understand. Once stdout blocks the whole program blocks, so it makes no difference that stderr is not piped. The program is stopped, it won't be making any errors. Obviously you could make some complicated buffering scheme - but you can do that and flush things anyway. The flush or no flush makes no difference.
- gte910h 17y agoOnly if you're using blocking IO. Just set O_NONBLOCK if you don't want blocking IO.
- ars 17y agoAKA "some complicated buffering scheme". Without blocking IO you have to buffer the output locally.
- gte910h 17y agoOr 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.
- ars 17y agoSigh. And the difference between "stop processing" and letting the IO block is what?
- gte910h 17y agoYou 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.