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 10:08:24

Oliver Kowalke-2 wrote:
> 
> Vicente Botet Escriba wrote:
>>
>> Oliver Kowalke-2 wrote:
>>   
>>> I've re factored boost.fiber (-> boost vault 
>>> http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming). 
>>>
>>>
>>> The library provides a so called lightweight thread of execution (also 
>>> known as user-space thread or fiber on WIN32).
>>> The API is modeled after boost.thread.
>>>
>>> Beside a scheduler (currently simple round-robin) for the fibers the 
>>> library provides sync. primitives like mutex, condition- and 
>>> event-variables (auto-reset, manual-reset, count-down). Message can be 
>>> passed between fibers via bounded-/unbounded-fifo.
>>>
>>> Some feedback would be nice.
>>>
>>>
>>>     
>> Just a remarks related to name space. Your namespace approach is mixed.
>> From
>> one side you have boost::this_fiber namespace and boost::fiber class and
>> the
>> namespace boost::fibers. IMO you should either put all on boost or on
>> boost::fibers but not both.
>>   
> I choosed the same style as boost.uuid and other libs:
> 
> namespace uuids
> { class uuid ... }
> 
> using uuids::uuid;
> 
> The problem is that some classes as mutex of boost.thread reside in 
> namespace boost (->boost::mutex). Thatswhy I put all classes into ns 
> boost::fibers. The class boost::fiber is a using clause in ns boost 
> (using boost::fibers::fiber).
> 
> I choosed boost::this_fiber because of the analogy to boost.thread 
> (boost::this_thread).
>> Instead of 
>>
>> boost::fiber f1=boost::fibers::make_fiber( some_fn);
>>
>> I would prefer 
>> boost::fiber f1=boost::make_fiber( some_fn);
>>   
> name collisions with boost::mutex, boost::condition etc.
> 

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.

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?

>> I have also some questions related to the scheduler. How many schedulers
>> can
>> be run on a thread? Do you have a use case of any interest to be able to
>> run
>> more than one?
>>   
> The intention is to use only one scheduler in a thread, but you can use 
> one scheduler in multiple threads.
> 

Could we say that we can have thread specific schedulers and multi-threaded
schedulers?

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.

>> Could you talk about the need to migrate fibers from one thread to
>> another?
>>   
> Be aware that sharing data between threads/cpus costs a lot of cpu cycles.
> In future work fibers maybe explicit migrated to other 
> threads/schedulers -> load balancing.
> 

Maybe it is worth considering migrating and non-migrating fibers respect to
threads and schedulers. What do you think?

What about having fiber specific storage, something like fiber_specific_ptr?
Would this be possible without breaking the current design?

What about a fiber barrier?

Have you explored how fibers and futures interact?

Let me know if I can help you on any task, I'm really interested in this
library. 

Continue the good work,
Vicente

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