Re: Flushing all Buffers Before Exiting
David Wright <deblis@lionunicorn.co.uk> writes:
> 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.
Apparently, the flush after each new cycle of data isn't
taxing the system too much as the output looks correct. This is
a 600 MHZ Pentium which would have gone in to the recycle bin
years ago if not for Linux. Older systems like this tend to
accentuate the effects of not being able to keep up much more
obviously than if this was a quad-core 64-bit modern design.
The best test I can do is to look at the output which is
quite repetitive as it is designed to allow radios to almost
immediately figure out what frequency and "talk group" they
should be on even if their owner turns on the radio in the middle
of a conversation. Subsequent lines all look the same so if one
is missing part of the data, it looks wrong especially if you
have watched enough of this gibberish to damage one's brain to
the point where it starts making sense.
Martin
Reply to: