Am Montag, 3. November 2008 16:42:47 schrieb Peter Dimov:
Anthony Williams:
No, I'm not sure, but if some_future.wait() switches to a new fiber I am concerned that it won't, because the exception state is per-thread, not per-fiber.
On second thought, yes, it might be possible to construct an example that breaks. You need to switch to another fiber in a catch clause, which then needs to throw _and_ switch back to you in a catch clause. Another problematic case is switching to another fiber during stack unwinding.
I'm not sure if this can happen in practice in a straightforward pool implementation that only yields on wait. A waits for B waits for A is a deadlock anyway.
-- Peter Dimov
We have a long thread of posts - but wat is the final conclusion? Using fibers to implement fork/join smeantics seams to introduce some other pitfalls (at least migration of fibers to other worker-threads). Recusrive scheduling of sub-task can create deadlocks too. ??? Oliver