On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote: > On Thu, Mar 21, 2019 at 07:52:33PM -0500, Martin McCormick wrote: > > [...] > > > Opening, appending and closing for each new line of > > output made me a bit squeamish. The program is monitoring a > > stream of data from a radio scanner. The data spew in at about > > 20 or 30 lines per second. > > Don't fear. Measure :-) > > Doesn't sound outrageous to line-buffer your output to file. > > The output to screen is already line-buffered (by default, > at least) and isn't killing you, so if I were you, I'd set > up a benchmark run and torture things a bit. Then, *if* you > notice any whiff of a problem, you could try a more clever > scheme like timeout based flush to better get hold of bursts > (if I understood your description, things go out in bursts).
Reading the OP's problem, I wonder how you're meant to detect "any whiff of a problem". All we know is that the maximum rate *might* be 30 lines per second, but is that a guess? Are we already losing the odd line? How would we replicate test runs? Probably not, at 30 lps, but in principal I would say that this is a sticking plaster while you write your better method. The main concern raised in the OP was flushing before termination, for which a signal is ideal. And for best performance, I'd forget tee and just look at the output file occasionally, with tail. Cheers, David.