Re: [boost] new library boost.fiber in vault

Subject: Re: [boost] new library boost.fiber in vault
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-11-22 15:41:13

Oliver Kowalke-2 wrote:
> 
> Vicente Botet Escriba wrote:
>> Ok I see. I'll put all the conflicting stuff on the namespace fibers, but
>> I
>> would let Non-member template function make_fiber() on boost namespace.
>> BTW,
>> it is not clear in the reference documentation on which namespace this
>> function is in.
>>   
> It's not a big thing to move make_fiber() etc. to boost namespace.
> I did found any advice in the boost documentation what is the preferred 
> way.
>> I have found also an incoherence between the implementation and the
>> documentation concerning the classes disable_interruption and
>> restore_interruption. They should be defined on the this_fiber namespace,
>> but I found them declared on boost::fibers. Am I missing a using
>> declaration?
>>   
> Thx - I'll correct this soon (including adding namspace).
>> Could we say that we can have thread specific schedulers and
>> multi-threaded
>> schedulers?
>>   
> Would be nice but requires a careful design.
>> I see that you plan to implement other scheduler features, e.g. taking
>> care
>> of priorities. I see also that  there are some functions that depends on
>> the
>> scheduler class. Of course we can have a single scheduler class that
>> would
>> take care of all the scheduler intricacies, but I think that it will
>> interesting to explore the possibility to have several models of a
>> Scheduler
>> concept, and see if making this possible don't would decrease the
>> performances or even if this could allow to improve them. If we would
>> have
>> specific schedulers, the current scheduler class would be just one of
>> them,
>> and should be named with its current specific purpose.
>>
>>   
> I plan to implement several scheduling algorithms selectable via an 
> enumeration passed to the ctor of the scheduler class.
> Another possibility would be to do make scheduler to an template and the 
> template argument specifies the scheduling algorithm (implementation).
> 
> template< typename Strategy >
> class scheduler;
> 
> scheduler< round_robin > rr_sched;
> scheduler< bfs > bfs_sched;
> 
> This would break the usage of boost::this_fiber::yield() for example, 
> because the functions in namespace boost::this_fiber access the 
> scheduler via a static member and need to know the exact type of the 
> scheduler.
> 
> 

Yes I have already remarked this fact. If we restraint to having only one
scheduler instance running on a thread, we can transform these static calls
to polymorphic calls. This will opens the introduction of schedulers
external to the library. The call of virtual functions could decrease the
performances of some functions, but a test on the enumeration should be
equivalent.

>> Maybe it is worth considering migrating and non-migrating fibers respect
>> to
>> threads and schedulers. What do you think?
>>   
> Sounds reasonable if we can get a correct working implementation.
> 

Well if I understand, up to now you have implemented non-migrating fibers.
The idea could be to introduce migrating fibers on a separated class, and
don't decrease the performances of a simple tool.

I have yet another question. I understand we need fibers::mutex and
fibers::condition_variable, but could you explain why do we need a separated
fibers::lock_guard and fibers::unique_lock template classes? Why the ones
from Boost.Thread are not usable in the fiber context, at the end the Mutex
parameter can be any model of lockable.

Best,
Vicente
-- 
View this message in context: http://old.nabble.com/new-library-boost.fiber-in-vault-tp26453013p26467888.html
Sent from the Boost - Dev mailing list archive at Nabble.com.