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.
After acquired, the caller 'owns' the thread handle and can inspect it,
the associated thread is defined to be waiting for a wakeup signal
(and then one shouldn't do unlocked access to the thread handle)
* commit 'dc87e78590ea86615d3ebe90d23af4548445b941':
add a two-thread acquire test
show the state of the thread in question
minor fixes: remove an old comment and change another
fix the prime test algorithm
use unsigned long for even more digits!
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
counting the threads had a race when creating threads, with moving
threads only between idle and working list we don't need the counters for
operation anyways. Maybe later when we find out that we need them we can
re-add them in a sane way
* plouj/second-tp-attempt:
use the largest prime that can fit in an it
don't expect a message about waiting anymore
scons: propagate PKG_CONFIG_PATH when checking for library
python-2.6 fix: loading the icon_rener.py script (Ticket #222)
Use a fully qualified name for PlacementMO in PlacementIndex
