Matthias Klose noted that on less powerful targets, a link might take more
than 5 minutes; he mentions a figure of 3 hours for an LTO link. So this
patch changes the timeout to a check for whether the locking process still
exists.
Alex, you had a lot of helpful comments when I first wrote this, any thoughts
on this revision?
---
gcc/lock-and-run.sh | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/gcc/lock-and-run.sh b/gcc/lock-and-run.sh
index 3a6a84c253a..404350b89a4 100644
--- a/gcc/lock-and-run.sh
+++ b/gcc/lock-and-run.sh
@@ -5,29 +5,28 @@ lockdir="$1" prog="$2"; shift 2 || exit 1
# Remember when we started trying to acquire the lock.
count=0
-touch lock-stamp.$$
-trap 'rm -r "$lockdir" lock-stamp.$$' 0
+trap 'rm -rf "$lockdir"' 0
until mkdir "$lockdir" 2>/dev/null; do
# Say something periodically so the user knows what's up.
if [ `expr $count % 30` = 0 ]; then
- # Reset if the lock has been renewed.
- if [ -n "`find \"$lockdir\" -newer lock-stamp.$$`" ]; then
- touch lock-stamp.$$
- count=1
- # Steal the lock after 5 minutes.
- elif [ $count = 300 ]; then
- echo removing stale $lockdir >&2
- rm -r "$lockdir"
+ # Check for stale lock.
+ pid="`(cd $lockdir; echo *)`"
+ if ps "$pid" >/dev/null; then
+ echo PID $$ waiting $count sec to acquire $lockdir from PID $pid>&2
+ found=$pid
else
- echo waiting to acquire $lockdir >&2
+ echo PID $pid is dead, removing stale $lockdir >&2
+ rm -r "$lockdir"
fi
fi
sleep 1
count=`expr $count + 1`
done
+touch $lockdir/$$
+echo PID $$ acquired $lockdir after $count seconds >&2
echo $prog "$@"
$prog "$@"
base-commit: aa45db50a034b266c338b55dee1b412178ea84a7
--
2.18.1
