Re: [boost] [fiber] on schedulers and wakeups

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Giovanni Deretta (gpderetta_at_[hidden])
Date: 2015-09-09 11:18:56

Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
> Giovanni Piero Deretta <gpderetta <at> gmail.com>:
> > Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
> > > Giovanni Piero Deretta <gpderetta <at> gmail.com>:
> > > > Oliver Kowalke <oliver.kowalke <at> gmail.com> writes:
> > > > >
> > > > > of course if this decision is given up, the user creates (on stack
> > or
> > > > heap)
> > > > > a scheduler
> > > > > and if a new fiber is created the code must specify to which
> > scheduler
> > > > the
> > > > > fiber belongs to.
> > > > >
> > > > > my_scheduler ms;
> > > > >
> > > > > fiber f( ms, fn, arg1, arg2),
> > > >
> > > > Specifying an explicit scheduler would be a nice addition, but if not
> > > > specified, it should default to the current scheduler for the thread.
> > >
> > > Hmmm, I would prefer if the scheduler and fiber interfaces were left
> > orthogonal. A fiber is just a callable,
> > 
> > A fiber itself is not just a callable though, it is logically a sequence
> > of
> > callables (each callable is the next continuation at wait and yield
> > points).
> > At each reschedule point, the fiber needs to know which executor need to
> > use
> > for the next continuation.
> 
> If a fiber is not a callable, then exposing it using a
> std::thread-compatible interface does not really makes sense.

I can't parse that. Certainly I wouldn't expect boost::fiber::fiber to be a
callable; then again, neither is std::thread.

> 
> > The same issue happen with plain 'executed' function object that need to
> > execute another continuation, it either needs to know the executor
> > explicitly or there must be a default (possibly thread specific one).
> 
> I don't see a reason not to expose the executor used to schedule the fiber.
> Something like
> 
> auto exec = this_fiber::get_executor()

oh, sure, I'm completely in favor of that; but I also think that there
should be a notion of an optional preferred fiber executor[1] (or
scheduler), which will be used in preference to the thread local executor
for plain  yields and wakeup (for example a
fiber::condition_variable::signal need to know where to schedule the woken
up fibers, and the thread local executor might not be the correct place).

[1] currently in Boost.Fiber this exists, and it is not optional.

-- gpd