On Sat, Jan 11, 2014 at 12:50 PM, Vicente J. Botet Escriba
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.