[Top][All Lists]

[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="";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]