Subject: Re: [boost] [threadpool] new version v12 - conclusion?
Date: 2008-11-03 13:52:45
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk