Lets talk about fibers

Joakim via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 3 18:51:24 PDT 2015


On Wednesday, 3 June 2015 at 18:34:34 UTC, Liran Zvibel wrote:
> There are two main reasons why it does not make sense to move 
> fibers between threads:
>
> 1. You'll start having concurrency issues. Lets assume we have 
> a main fiber that received some request, and it spawns 3 fibers 
> looking into different DBs to get some info and update an array 
> with the data. The array will probably be on the stack of the 
> first fiber. If fibers don't move between threads, there is 
> nothing to worry about (as expected by the model). If you start 
> moving fibers across threads you have to start guarding this 
> array now, to make sure it's still coherent.
> This is a simple example, but basically shows that you're 
> "losing" one of the biggest selling point of the whole reactor 
> based model.
>
> 2. Fibers and reactor based IO make work well (read: make 
> sense) when you have a situation where you have lots of 
> concurrent very small transactions (similar to the Web C10k 
> problem or a storage machine). In this case, if one of the 
> threads has more capacity than the rest, then the IO scheduler 
> ("reactor") will just make sure to spawn new fibers accepting 
> new transactions in that fiber. If you don't have a situation 
> that balancing can be done via placing new requests in the 
> right place, then probably you should not use the reactor 
> model, but a different one that suits your application better.
> Currently we can spawn another reactor to take more load, but 
> the load is balanced statically at a system-wide level. On 
> previous projects we had several reactors running on different 
> threads and providing very different functionality (with 
> different handlers, naturally).
> We never got to a situation that moving a fiber between threads 
> made any sense.
>
> As we see, there is nothing to gain and lots to lose by moving 
> fibers between threads.

Your entire argument seems based on fibers moving between threads
breaking your reactor IO model.  If there was an option to
disable fibers moving or if you had to explicitly ask for a fiber
to move, your argument is moot.

I have no dog in this fight, just pointing out that your argument
is very specific to your use.


More information about the Digitalmars-d mailing list