2015-09-09 0:19 GMT+02:00 Giovanni Piero Deretta
: On Tue, Sep 8, 2015 at 7:21 PM, Oliver Kowalke
wrote: 2015-09-08 13:34 GMT+02:00 Giovanni Deretta
: My first concern is that scheduler is a global (per thread)
makes sense, but it limits its usability in libraries, unless the
Oliver Kowalke
writes: property. This 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 ...).
The point is that the scheduler is not completely invisible as it can be replaced. As the default scheduler is very basic, replacing it becomes pretty much a requirement.
of course if this decision is given up, the user creates (on stack or
a scheduler and if a new fiber is created the code must specify to which scheduler
heap) 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, its API shouldn't have a notion of where it is run. I'd like to see something like this instead:
// asynchronous execution
T fn(Arg...) {...}
fiber_executor exec;
future<T> f = executor_traits
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?!
As I suggested elsethread, a child scheduler would appear to the parent scheduler as another fiber, so if that fiber is migrated, the whole scheduler is.
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)
Ok, I think I understand; I was thinking about fiber the abstract concept, while you of course meant the boost::fiber::fiber class, which can be detached like an std::thread.
Although now I can't see how detaching is relevant to the nested scheduler discussion...
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu