[Piglit] [PATCH 4/4] framework: Repair result file if test run is interrupted

Ian Romanick idr at freedesktop.org
Mon Jul 25 10:39:40 PDT 2011

Hash: SHA1

On 07/25/2011 10:31 AM, Chad Versace wrote:
> On 07/23/2011 01:30 AM, Ian Romanick wrote:
>> On 07/19/2011 12:36 PM, Chad Versace wrote:
>>> If the JSON result file was not closed properly, perhaps due a system
>>> crash during a test run, then TestrunResult.parseFile will attempt to
>>> repair the file before parsing it.
>> What happens if I run piglit-summary-html.py on a set of results while
>> piglit-run.py is generating those results?  Will it attempt to "repair"
>> the output of the in-progress test results?  Will this make everything
>> explode?
> I did not consider this, since I only run piglit-summary-html.py
> after the test run has finished. Your fear is accurate. It will
> attempt to "repair" the in-progress result file and hence destroy
> it.

I'm sure that's how most people do it most of the time.  I thought of
this when I was running piglit in a loop over several Mesa versions.
After one of the passes I wanted to regenerate the HTML results for a
subset of my results directory.  I almost gave it a wildcard to pick the
directories, but right before pressing 'enter', I remembered new repair

> I see a simple way to fix this. Currently, TestrunResult.__repairFile
> 1) copies the result file into a buffer, 2) repairs the buffer's
> contents, and 3) then overwrites the result file with the buffer. To
> fix this problem, we can replace step 3 with: return the buffer as
> the repaired file. This way, __repairFile() never overwrites the
> result file.

That sounds like it should work around the problem.  The alternative of
using file locks is the stuff nightmares are made of.
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


More information about the Piglit mailing list