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

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-09-09 16:04:52

> > > 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.

I didn't make myself clear, sorry. What I meant is that a fiber 'represents
a callable', not 'is a callable'. So does 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.

We're in agreement here.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu