Lets talk about fibers

[via Digitalmars-d]

On Thursday, 4 June 2015 at 13:42:41 UTC, Liran Zvibel wrote:
> If you assume that new jobs always come in (and then you 
> schedule new jobs to the more-empty fibers), there is no need 
> to balance old jobs (That will finish very soon anyway).

That assumes that the tasks don't do much work but just wait and 
wait and wait.


>
> If you have a blocking operation it should not be in fibers 
> anyways.
> We have a deferToThread mechanism with a thread pool that waits 
> for such functions (if we want to do something that takes some 
> time, or use external library).
> Fibers should never ever block. If your fiber is blocking 
> you're violating the model.
>
> Fibers aren't some magic to solve every CS problem possible.

Actually, co-routines have been basic concurrency building blocks 
since the 50s, and from a CS perspective the degree of 
parallelism is an implementation detail.

> Looking at your example -- a good scheduler should have 
> distributed a-e evenly across both cores to begin with.

Nah, because that would require an a priori estimate.

> Then a good fibers programmer should yield() after each unit of 
> work, so aaaaaaa won't be a valid state.

Won't work when you call external libraries. Here is a likely 
pattern for an image scaling service:

1. check cache
2. request data if not found
3. process, save in cache and return

1____________2____________33333333

You can't just break up workload 3, you would run out of memory.