Wed, 15 Apr 2015 01:16:40 -0400 unbundle: acquire 'wlock' when processing bundle2 (BC) (issue4596)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 01:16:40 -0400] rev 24752
unbundle: acquire 'wlock' when processing bundle2 (BC) (issue4596) A bundle2 may contain bookmark updates (or other extension content) that requires the 'wlock' to be written. As 'wlock' must be acquired before 'lock', we must stay on the side of caution and use both in all case to ensure their ordering.
Sun, 12 Apr 2015 09:46:03 -0400 run-test: enable the devel warning during tests
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 09:46:03 -0400] rev 24751
run-test: enable the devel warning during tests This should help us to catch new locking order issues as soon as possible. There are two harmless test updates (from the config change). Moreover, some bundle2 tests are displaying warning for a legitimate reason. The use of pushkey during the unbundle process may requires the 'wlock' after 'lock' (around the whole unbundle process was taken). This is non-trivial to fix, so I better have the check on, with the warning in the test than the check off. See issue4596 for details.
Sun, 12 Apr 2015 15:37:59 -0400 wlock: do not warn for non-wait locking
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 15:37:59 -0400] rev 24750
wlock: do not warn for non-wait locking We are warning about lock acquired in the wrong order because this can create dead-lock situation. But non-wait acquisition will not block and therefore not create a dead-lock. So we do not need to wait in such case.
Sun, 12 Apr 2015 14:27:42 -0400 develwarn: include call site in the simple message version
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 14:27:42 -0400] rev 24749
develwarn: include call site in the simple message version Just displaying the warning makes it quite hard to recognise the guilty code quickly and using --traceback for all calls is not very convenient. So we include the call site with all simple message to help developer to recognise errors sources.
Sun, 12 Apr 2015 14:26:11 -0400 develwarn: handle the end of line inside the function itself
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 14:26:11 -0400] rev 24748
develwarn: handle the end of line inside the function itself The traceback version should not have a end of line at all. The non-traceback version will requires the same things soon.
Sun, 12 Apr 2015 14:24:28 -0400 develwarn: refactor the developer warning logic
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 14:24:28 -0400] rev 24747
develwarn: refactor the developer warning logic The logic is currently duplicated and we plan to make it a bit smarter. So we move it into a function first to make the update more robust and simple.
Wed, 15 Apr 2015 01:20:48 -0400 lock: update the docstring with order information
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 01:20:48 -0400] rev 24746
lock: update the docstring with order information Lock must be acquired in a specific order to avoid dead-lock. This was documented on the wiki, but having this information in the docstring is also useful.
Sun, 12 Apr 2015 13:28:35 -0400 wlock: reword the devel warning
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 13:28:35 -0400] rev 24745
wlock: reword the devel warning We change the wording of the developer warning: - "lock" taken before "wlock" + "wlock" acquired after "lock" The goals here are to: - Put the "subject" as the first word, - use "acquired" instead of "taken" since it seems more accurate.
Sun, 12 Apr 2015 10:01:48 -0400 wlock: only issue devel warning when actually acquiring the lock
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 10:01:48 -0400] rev 24744
wlock: only issue devel warning when actually acquiring the lock Before this change, any call to 'wlock' after we acquired a 'lock' was issuing a warning. This is wrong as the 'wlock' have been properly acquired before the 'lock' in a previous call. We move the warning code to only issue such warnings when we are acquiring the 'wlock' -after- acquiring 'lock'. This is the expected behavior of this warning from the start.
Sat, 11 Apr 2015 17:30:45 -0400 bundle2: flush output in a part in all cases
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 11 Apr 2015 17:30:45 -0400] rev 24743
bundle2: flush output in a part in all cases We want to preserve output even when the unbundling fails (eg: hook output). So we must make sure that everything we have is flushed into the reply bundle. (This is related to issue4594)
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip