Boost logo

Boost :

Subject: Re: [boost] [threadpool] new version v12 - conclusion?
From: k-oli_at_[hidden]
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, gregod at, cpdaniel at, john at