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

2015-09-09 0:19 GMT+02:00 Giovanni Piero Deretta :

...

2015-09-08 13:34 GMT+02:00 Giovanni Deretta :

...

My first concern is that scheduler is a global (per thread) property. This makes sense, but it limits its usability in libraries, unless the

On Tue, Sep 8, 2015 at 7:21 PM, Oliver Kowalke wrote: 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)