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

Subject: Re: [boost] new library boost.fiber in vault
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2009-11-21 13:52:54

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.
> 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 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.
> Thanks,
> Vicente
>   
regards,
Oliver