[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10470: MSYS: race in directory access?
From: |
Peter Rosin |
Subject: |
bug#10470: MSYS: race in directory access? |
Date: |
Tue, 10 Jan 2012 14:13:44 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
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
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/09
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/09
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/10
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/10
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/10
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/10
- bug#10470: MSYS: race in directory access?, Eric Blake, 2012/01/10
- bug#10470: MSYS: race in directory access?,
Peter Rosin <=
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/10
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/10
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/10
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/10
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/11
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/11
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/12
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/12
- bug#10470: MSYS: race in directory access?, Stefano Lattarini, 2012/01/13
- bug#10470: MSYS: race in directory access?, Peter Rosin, 2012/01/13