Re: Flushing all Buffers Before Exiting
On Sat 23 Mar 2019 at 18:23:47 (+0100), tomas@tuxteam.de wrote:
> On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > On Fri 22 Mar 2019 at 17:45:50 (+0100), tomas@tuxteam.de wrote:
>
> > Reading the OP's problem, I wonder how you're meant to detect
> > "any whiff of a problem" [...]
>
> Torture tests.
Like, multiply the number of sources by stealing a few more radio
scanners to connect up, which then all burst into life as the
police scour the neighbourhood for thieves?
When dealing with realtime real information coming in, over which you
have no control, it can be non-trivial to set up such scenarios.
That's why I thought it best to devise a method that's more
efficient than line buffering. After all, that's why buffering
was invented, wasn't it.
> > 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.
>
> A signal handler is definitely an option, but it can be pretty tricky.
> Especially if you are catching things like SEGV (you dare a write()
> after that?)
SIGUSR1 to flush the buffers; that's all (see Subject line). If you
find progamming it tricky, that's a good reason for line buffering as
a stopgap. What would I do with SEGV, having trapped it? (Or most of
the other signals…)
Cheers,
David.
Reply to: