- detail:.scheduler was removed
- fiber_context has a static thread-local pointer to the active
fiber_context
- fiber_context has member to pointer of fiber_manager
- functions of fiber_manager are accessed only via fiber_context
- if fiber f is resumed, the fiber_manager of the current active fiber
f' is assigned to f
-> that is necessary if f was stolen form another thread
When the running thread's main fiber calls this_fiber::properties<>() without
yet having passed through sched_algorithm_with_properties::awakened(), which
is what actually instantiates the fiber_properties subclass, you could end up
without a properties instance. Fortunately there's an easy workaround: call
yield().
Remove that workaround from examples/priority.cpp.
sched_algorithm_with_properties<> must intercept awakened() calls before
forwarding control to the subclass override. That pretty much requires two
different virtual methods: one for sched_algorithm subclasses WITHOUT
properties, the other for sched_algorithm_with_properties subclasses.
Originally we used a different name (awakened_props()), but that was
bothersome. It makes more sense to use a different awakened() overload
instead, one that passes in the relevant properties object.
Fix examples/priority.cpp accordingly.
Also delegate instantiation of a new properties object to new_properties()
virtual method. Overriding this method allows you to customize allocation,
instead of sched_algorithm_with_properties<> unconditionally putting the new
properties object on the heap. Validate the new_properties() return value.
This could either be because the thread's current sched_algorithm is not a
subclass of sched_algorithm_with_properties (e.g. set_scheduling_algorithm()
was never called for this thread, so round_robin is in use), or because the
fiber has not yet reached execution. A fiber's properties are instantiated
when it is first scheduled.
