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

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-09 00:09:32

2015-09-09 0:19 GMT+02:00 Giovanni Piero Deretta <gpderetta_at_[hidden]>:

> On Tue, Sep 8, 2015 at 7:21 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]>
> wrote:
> > 2015-09-08 13:34 GMT+02:00 Giovanni Deretta <gpderetta_at_[hidden]>:
> >
> >> My first concern is that scheduler is a global (per thread) property.
> This
> >> makes sense, but it limits its usability in libraries, unless the
> library
> >> completely owns a thread.
> >
> >
> > the scheduler is only entered if a function from boost.fiber is called.
> > code outside of fiber code is ‎unaffected
> > how does it limit the usability?
> >
>
> Two different libraries can't use boost.fiber if they require a custom
> scheduler or they need to run their own threads. Basically the
> scheduler is a scarce resource and limits composability.
>

OK, good point!
One of the design decisions for boost.fiber was that the scheduler itself
is not visible
(the user code does not instantiate it). the library should work similar to
std::thread
(os-scheduler not visible ...).

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),
f.join();

in the context of migrating fibers between threads:

- in the current design only single fibers are moved between schedulers
running in different threads
- you suggest that the scheduler itself is moved between threads?!

>
> > It would be nice if schedulers where schedulable
> >> entities themselves, so that they could be nested (more at the end).
> >>
> >
> > in the current design each thread has one scheduler (the scheduler is
> > hidden).
> > a scheduleable entity is a fiber context (fiber's stack), that means that
> > each boost::fibers::fiber
> > is attached to one fiber context (detaching a fiber means decoupleing
> from
> > the context).
>
> how do you detach a fiber by a context? What does it mean? Did you
> mean detach a fiber+context from a scheduler?
>

boost::fibers::fiber has a member pointer to boost::fibers::context
boost::fibers::scheduler manages boost::fibers::context *
detaching means boost::fibers:.fiber relases its pointer to
boost::fibers::context.

the scheduler still manages (scheduling/lifetime) the detached context
(boost::fibers::context is a control structure
residing on the top of the fiber-stack)