After removing the explicit locking, there is a small
race in case of a "floundering" (simulated) subsystem:
the starting context may go away before the child thread
actually teminates. I consider this a shortcoming of
this test fixture, which isn't intended to be an example
of a real world subsystem, but rather focusses on
error detection within the subsystem runner.
Added some more fuzz and sleeping to the test calculation to have a actual
chance to fail when something is not well locked.
Using a premature classlock, locking instances was insufficient.
using new thread synchronization
Disabled further tests, making one after another working.
Some notes:
* currently running this leads to different outcomes on differnt runs,
there are some races/unsyncronized things left, to be investigated.
* I suggest to make Subsystems joinable, this prolly needs some work in
the error handling department (thread-wrapper.hpp too)
* using nonrecursive/waitable lock, recursive locks are have some bad
taste unless absolutely necessary
* after all a timed lock with polling is not the right approach to check
for subsystem shutdowns, I opted against thread cancelation because of
its programming overhead and complexity. We may refine this and allow
synchronous cancellation (with an approbiate thread flag) in some cases.
This removes the explicit Sync things from the thread wraper since
the functionality is almost exactly provided by the backend.
Thread encapsulates a lumiera thread handle now, but this is strictly
optional and might be dropped on the floor (using a temporary as thread).
Thread has a sync() function which allows user controlled syncronous
startup:
Thread("foo", myoperation).sync();
will startup myoperation and only return from the ctor after myoperation
called a matching lumiera_thread_sync().
The related tests need to initialize/destroy the threadpool accordingly
