As discussed in #6565, we don't want to introduce a dependency on boost 1.50, since debian wheezy.
This fixes #6394, but without using boost::reverse_lock.
Fix #6394 without boost dependency. #6608
pull casey wants to merge 1 commits into bitcoin:master from casey:scheduler-lock changing 1 files +6 −5-
casey commented at 4:58 PM on August 31, 2015: contributor
- casey cross-referenced this on Aug 31, 2015 from issue Make sure we re-acquire lock if a task throws by casey
-
sipa commented at 4:59 PM on August 31, 2015: member
Are you sure this re-locks if no exception is thrown?
-
casey commented at 5:03 PM on August 31, 2015: contributor
Sorry, I missed a line, fixed.
-
dcousens commented at 5:13 PM on August 31, 2015: contributor
ACK, but IMHO I don't see why not to just bump to boost 1.50.
-
-
theuni commented at 5:31 PM on August 31, 2015: member
@dcousens This is not about "us" bumping boost, it's about us failing to compile in environments that would otherwise compile fine.
It's fine to require a newer version if it brings big new features that'd be hard to match without it, but in this case I don't think it's worth it. Concept ACK on the approach here.
-
Fix #6394 without boost dependency. b403dec16a
-
-
laanwj commented at 3:44 PM on September 3, 2015: member
I like this solution better than #6610. At least it scopes the lock(), instead of depending on an extra call to
lock.owns_lock()to determine where the exception came from.Although implementing a RAII reverse_lock of our own would have my preference, it's the cleanest solution.
- casey cross-referenced this on Sep 3, 2015 from issue Replace boost::reverse_lock with our own by casey
-
-
laanwj commented at 7:47 PM on September 3, 2015: member
Closing (#6630)
- laanwj closed this on Sep 3, 2015
- bitcoin locked this on Sep 8, 2021
