Ichthyostega
08c3e76f14
On a close look, the wrapper design as pursued here turns out to be prone to insidious data race problems. This was true also for the existing solution, but becomes more clear due to the precise definitions from the C++ standard. This is a confusing situation, because these races typically do not materialise in practice; due to the latency of the OS scheduler the new thread starts invoking user code at least 100µs after the Wrapper object is fully constructed (typically more like 500µs, which is a lot) The standard case (lib::Thread) in its current form is correct, but borderline to undefined behaviour, and any initialisation of members in a derived class would be off limits (the thread-wrapper should not be used as baseclass, rather as member) |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||