Make a copy of the boost time-point to wait for, otherwise the head of
the queue may be deleted by another thread while this one is waiting,
while the boost function still has a reference to it.
Although this problem is in non-test code, this is not an actual problem
outside of the tests because we use the thread scheduler with only one
service thread, so there will never be threads fighting at the head of
the queue.
The old boost fallback escapes this problem because it passes a scalar
value to wait_until instead of a const object reference.
Found by running the tests in LLVM-4.0-master asan.
Don't clear `stopRequested` and `stopWhenEmpty` at the top of
`serviceQueue`, as this results in a race condition: on systems under
heavy load, some of the threads only get scheduled on the CPU when the
other threads have already finished their work. This causes the flags to
be cleared post-hoc and thus those threads to wait forever.
The potential drawback of this change is that the scheduler cannot be
restarted after being stopped (an explicit reset would be needed), but
we don't use this functionality anyway.
On a busy or slow system, the CScheduler unit test could fail because it
assumed all threads would be done after a couple of milliseconds.
Replace the hard-coded sleep with CScheduler stop() method that
will cleanly exit the servicing threads when all tasks are completely
finished.
isle2983