builder.py: refresh the File object after obtaining the lock.

We need to create the File object to get its f.id, then lock that id.
During that gap, another instance of redo may have modified the file or
its state data, so we have to refresh it.

This fixes 'redo -j10 t/stress'.
This commit is contained in:
Avery Pennarun 2018-10-13 01:30:42 -04:00
commit 887df98ead
2 changed files with 6 additions and 6 deletions

View file

@ -121,9 +121,6 @@ class BuildJob:
# For example, a rule called default.c.do could be used to try
# to produce hello.c, but we don't want that to happen if
# hello.c was created by the end user.
# FIXME: always refuse to redo any file that was modified outside
# of redo? That would make it easy for someone to override a
# file temporarily, and could be undone by deleting the file.
debug2("-- static (%r)\n" % t)
sf.set_static()
sf.save()
@ -348,6 +345,12 @@ def main(targets, shouldbuildfunc):
log('%s (locked...)\n' % _nice(t))
locked.append((f.id,t))
else:
# We had to create f before we had a lock, because we need f.id
# to make the lock. But someone may have updated the state
# between then and now.
# FIXME: separate obtaining the fid from creating the File.
# FIXME: maybe integrate locking into the File object?
f.refresh()
BuildJob(t, f, lock, shouldbuildfunc, done).start()
state.commit()
assert(state.is_flushed())

View file

@ -29,6 +29,3 @@ sed 's/\.do$//' | {
redo "$d"
done
}
# if all that worked run a repeated stress test to look for races
redo stress