Subject: bug#10470: MSYS: race in directory access?

From: Peter Rosin <[email-masked]>
Date: Tue, 10 Jan 2012 14:13:44 +0100

Stefano Lattarini skrev 2012-01-10 13:44:
> On 01/10/2012 12:35 PM, Peter Rosin wrote:
>> Peter Rosin skrev 2012-01-10 11:12:
>>> Stefano Lattarini skrev 2012-01-10 10:50:
>>>> [2] Now that I think of it, my knee-jerk guess is that the "( sleep 1 ) &"
>>>>     put in configure by AM_SANITY_CHECK is the likely culprit.
>>>
>>> I tried that hypothesis and bumped this to "( sleep 2 ) &", and the test
>>> case failed even with my ugly "sleep 1" workaround.  I then bumped "my" fix
>>> to "sleep 2" and the test case succeeded again.  So they certainly seem
>>> connected.
>>
>> One further data point; changing that "( sleep 1 ) &" thing followed by a
>> wait just before AC_OUTPUT into an inlined sleep also fixes the test case.
>>
> Thanks for tracking this down.  So the question now becomes: why doesn't
> the trick with background processes work on MSYS?  Does maybe MSYS lack
> proper emulation of POSIX-ish PIDs?  If that is the case, can we easily
> work around that in our situation?

No no, that's not the problem.  In this case "make distcheck" runs
configure, but configure fails so it never reaches AC_OUTPUT and
the wait call never happens.  So, the ( sleep 1 ) subshell lives on
and "locks" the directory (but something else is also going on,
because changing the subshell to do ( cd /; sleep 1 ) doesn't help).

*pling* new mail, from Eric.

He explains the issue with different words and suggests:

"As for what somewhere/safe should be, $(abs_builddir) is probably
 reasonable."

So, testing that too, but neither cd /, nor cd "$(abs_builddir)" make
the test pass. Crap.

We could fix it in the testsuite only, by adding a trap to configure
that does the wait if it didn't happen before, but that would make
use of internals that would perhaps spread. Yuck again.

Cheers,
Peter