[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Please test with WRITE_PAD zeroed
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] Please test with WRITE_PAD zeroed |
Date: |
Sun, 15 Feb 2015 18:27:09 -0500 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hal Murray <address@hidden>:
> Note that only 4 out of 5 got counted. I assume the no-diff case had the
> timeout after all the data and either didn't return an error code or the
> wrapper didn't check the return code.
That's probably right.
> [Context is reducing printout after known error like timeout,]
> > I will, but I need to make sure suppressing the diff output doesn't discard
> > its intended use - catching incorrect changes in the driver code leading to
> > incorrect packet parsing.
>
> How about skipping the printout if the output file is empty?
Possible. It'll make regress-driver more complicated, but is
probably worth that.
> [100% of CPU]
> > Given that it's pumping test logs into a pty as fast as it can, this is not
> > vey surprising.
>
> Why is it getting a timeout if it's pumping stuff into a log file?
The timeout happens when gpsd gets stuck waiting on a select because it never
sees the injected "# EOF\n" at the end of the testload. Python eating the
CPU is what's happening at the *other* end of the pipe.
> The 100% CPU that I observed was while it was waiting for things to time out.
> Most tests only take a few seconds. There is plenty of time to catch it
> while it is timing out.
I do not quite understand what you are driving at here.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>