[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testsuite failure - 193 parallel execution

From: Eric Blake
Subject: Re: testsuite failure - 193 parallel execution
Date: Tue, 20 Jul 2010 15:15:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5

On 07/20/2010 03:11 PM, Eric Blake wrote:
> On 07/20/2010 03:05 PM, Paul Eggert wrote:
>> Staring at the code some more I see another race condition
>> that could explain the problem.  Suppose the parent, just
>> after the last fork, races ahead of the child and jumps
>> ahead to the "read at_token" cleanup loop.  The parent then
>> executes the last "read at_token" cleanup at a point
>> where the second-to-the-last child has already output
>> its token, but before the second-to-the-last-child has
>> closed the fifo.  The "read at_token" will then return 0 (because
>> it sees end-of-file), but the parent incorrectly thinks
>> that it has seen a token and then closes down the fifo
>> before the last child gets a chance to write its token.
> Hmm, maybe we should do more validation in the parent - not just read
> from the fifo, but validate that we actually read a token.  That way, we
> can ignore EOF (on the grounds that it may be a temporary condition, and
> that more children remain to be run) and only advance when the token we
> read back is non-empty.

But for that to work, the token has to be more than a newline (since
read strips newlines).  So we're back to the QoI issue of whether all
shells output a newline as part of their echo (or maybe we switch over
to printf - so far, all shells decent enough to support parallel tests
also have a working printf(1) builtin).

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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