Make sure we re-acquire lock if a task throws

[casey]

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.

[sipa]

utACK.

[dcousens]

Couldn't this be done using a scope bound, RAII locking mechanism instead?

utACK

[casey]

@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]

I like the reverse lock approach :)

[casey]

Re-wrote it with a reverse_lock, it's much nicer now

[sipa]

utACK

[dcousens]

utACK, good find @casey

[laanwj]

/me really likes this solution. An inverse lock :-)
utACK.

[theuni]

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]

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]

I see no reason why we wouldn't be able to bump?

[pstratem]

Debian wheezy is 1.49 please do not bump the required version.

[jonasschnelli]

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]

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?

[casey]

Opened PR #6608, to revert and fix without a boost dependency.