2014/1/9 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
struct X {
operator bool() {} };
struct Y { operator bool() {} };
X x; Y y;
if ( x == y) // does compile
I don't see the problem with explicit conversion
you can compare X and Y
Is there an example showing this on the repository?
no its is an implementation in side the framework, e.g. class scheduler which holds the user-defined or the default implementation of the scheduler-impl (default is round_robin)
Can the scheduler be shared between threads?
no - not the schedulers (== classes derived from interface algorithm, e.g. round_robin and round_robin_ws) which might be share-able between threads but I doubt that it would make sense - a scheduler derived from alogrithm schedules the fibers running in the current thread
Maybe schedulers need to take care of a single time_point, but the other
classes should provide an time related interface using any clock.
OK - boost.chrono is your domain. functions accepting a time_duration/time_point (from boost.chrono) can always be mapped/applied to steady_clock/system_clock?
No mapping can be done between clocks and there is no need to do this mapping. This is how standard chrono libray was designed. Please take a look at the following implementation
template <class Clock, class Duration> bool try_lock_until(const chrono::time_point<Clock, Duration>& t) { using namespace chrono; system_clock::time_point s_now = system_clock::now(); typename Clock::time_point c_now = Clock::now(); return try_lock_until(s_now + ceil<nanoseconds>(t - c_now)); } template <class Duration> bool try_lock_until(const chrono::time_point<chrono::system_clock, Duration>& t) { using namespace chrono; typedef time_point<system_clock, nanoseconds> nano_sys_tmpt; return try_lock_until(nano_sys_tmpt(ceil<nanoseconds>(t.time_ since_epoch()))); }
Note that only the try_lock_until(const chrono::time_point<chrono::system_clock, nanoseconds>& ) function needs to be virtual.
seem to me at the first look that it woul be compilcate in teh case of boost.fiber because: - the scheduler (derived from algorithm, e.g. for instance round_robin) uses internally a specific clock type (steady_clock) - member-functions of sync classes like condition_variable::wait_for() takes a time_duration or condition_variable::wait_until() a time_point time_duration + time_point can be of arbitrary clock-type from boost.chrono? can I simply add a time_duration different fro msteady_clock to steady_clock::now()?
I made some adaptations to boost::barrier that could also have a sens for
fibers.
OK - what are those adaptations?
See
http://www.boost.org/doc/libs/1_55_0/doc/html/thread/ synchronization.html#thread.synchronization.barriers and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/ n3817.html#barrier_operations
OK - that's new to me, but I don't know the use case of completion function etc. - do you have some hints?
From the pointed proposal "
A Note on Completion Functions and Templates
The proposed barrier takes an optional completion function, which may either return void or size_t. A barrier may thus do one of three things after all threads have called |count_down_and_wait()|:
* Reset itself automatically (if given no completion function.) * Invoke the completion function and then reset itself automatically (if given a function returning void). * Invoke the completion function and use the return value to reset itself (if given a function returning size_t)."
As you can see this parameter is most of the time related to how to reset the barrier counter.
ready this too but do you have an example code demonstrating a use case, sorry I've no idea which use cases would require a completion function?