Re: [boost] Boost.Fiber - interruptible fibers

Subject: Re: [boost] Boost.Fiber - interruptible fibers
From: Nat Goodspeed (nat_at_[hidden])
Date: 2014-01-11 13:40:30

On Sat, Jan 11, 2014 at 12:50 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:

> Boost.Thread interruption feature adds some overhead to all the
> synchronization functions that are interruption_points.
> It is too late for Boost.Thread, but what do you think about having a simple
> fiber class and an interruptible::fiber class?

That's particularly interesting in light of recent remarks about the
cost of thread-safe fiber state management.

Going out on a limb...

Could we identify an underlying interruption-support operation and
tease it out into a policy class? Maybe "policy" is the wrong word
here: given the number of Fiber classes that would engage it, adding a
template parameter to each of them -- and requiring them all to be
identical for a given process -- feels like the wrong API. As with the
scheduling algorithm, what about replacing a library-default object?
Is the interruption-support overhead sufficiently large as to dwarf a
pointer indirection that could bypass it?

Similarly for fiber state management thread safety:

Could we identify a small set of low-level internal synchronization
operations and consolidate them into a policy class? Maybe in that
case it actually could be a template parameter to either the scheduler
or the fiber class itself. I'd still be interested in the possibility
of a runtime decision; but given a policy template parameter, I assume
it should be straightforward to provide a particular policy class that
would delegate to runtime.

Then again, too many parameters/options might make the library
confusing to use. Just a thought.