This fixes #6394
Pretty simple, it just makes sure to re-acquire the lock in case f throws, so that we don't touch nThreadsServicingQueue without the lock. The empty throw statement re-raises the current exception.
Make sure we re-acquire lock if a task throws #6565
pull casey wants to merge 1 commits into bitcoin:master from casey:scheduler-lock changing 1 files +7 −5-
casey commented at 9:35 PM on August 17, 2015: contributor
-
sipa commented at 10:21 PM on August 17, 2015: member
utACK.
-
dcousens commented at 2:28 AM on August 18, 2015: contributor
Couldn't this be done using a scope bound, RAII locking mechanism instead?
utACK
-
casey commented at 4:04 AM on August 18, 2015: contributor
@dcousens: Oh, hey, it looks like there actually is a reverse lock: http://www.boost.org/doc/libs/1_55_0/doc/html/thread/synchronization.html#thread.synchronization.other_locks.reverse_lock
I'll reimplement tomorrow, should be much cleaner.
-
sipa commented at 5:44 AM on August 18, 2015: member
I like the reverse lock approach :)
-
Make sure we re-acquire lock if a task throws fb08d92312
-
casey commented at 2:41 PM on August 18, 2015: contributor
Re-wrote it with a reverse_lock, it's much nicer now
-
sipa commented at 2:45 PM on August 18, 2015: member
utACK
-
-
laanwj commented at 2:25 PM on August 19, 2015: member
/me really likes this solution. An inverse lock :-) utACK.
- laanwj merged this on Aug 19, 2015
- laanwj closed this on Aug 19, 2015
- laanwj referenced this in commit a6f2affde8 on Aug 19, 2015
- laanwj added the label Bug on Aug 19, 2015
-
theuni commented at 8:37 PM on August 20, 2015: member
boost::reverse_lock is new as of 1.50 :(
We either need to set that as the minimum version required or work out a different fix here.
-
casey commented at 9:05 PM on August 20, 2015: contributor
The reverse lock implementation is very simple. If we can't bump the minimum required boost version to 1.50, I could copy pasta it in.
Alternatively we could just go back to the first implementation, which, although ugly, works fine.
-
dcousens commented at 9:58 PM on August 20, 2015: contributor
I see no reason why we wouldn't be able to bump?
-
pstratem commented at 7:59 AM on August 30, 2015: contributor
Debian wheezy is 1.49 please do not bump the required version.
-
jonasschnelli commented at 8:12 AM on August 30, 2015: contributor
Also ran into the same problem like @pstratem. I solved it with a dist upgrade to jessie... which is somehow not ideal. Support for boost 1.49 would be good but not urgently necessary.
-
dcousens commented at 8:49 AM on August 30, 2015: contributor
Boost 1.49 was released on February 24th, 2012. Boost 1.50 was released on June 28th, 2012. Debian 7.8 was released on January 10th, 2015.
Why the lag on a 4-month older package?
-
- MarcoFalke locked this on Sep 8, 2021
