Lets talk about fibers

[Liran Zvibel via Digitalmars-d]

On Thursday, 4 June 2015 at 01:51:25 UTC, Joakim wrote:
> 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.

This is not "my" reactor IO model, this is the model that was 
popularized by ACE in the '90 (and since this is how I got to 
know it this is how I call it), and later became the asyncio 
programming model.
This model was important enough for Guido Van Rossum to spend a 
lot of his time to add to Python, and Google created a whole 
programming language around [and I can give more references to 
that model if you like].

My point is that moving fibers between threads is difficult to 
implement and makes the model WEAKER. So you work hard, and get 
less (or just never use that feature you worked hard on as it 
breaks the model).

The main problem with adding flexibility is that initially it 
always sounds like a "good idea". I just want to stress the point 
that in this case it's actually not such a good idea.

If you can come up with another programming model that leverages 
fibers (and is popular), and moving fibers between threads makes 
sense in that model, then I think the discussion should be how 
stronger that other model is with fibers being able to move, and 
whether it's worth the effort.

Since I think you won't come up with a very good case to moving 
them between threads on that other popular programming model, and 
since it's difficult to implement, and since it already makes one 
popular programming model weaker -- I suggest not to do it.

Currently asyncio is supported by D (Vibe.d and Weka.IO are using 
it) well without this ability.

At the end of my post I suggested to use the resources freed by 
not-moving-fibers differently and just endorse the asyncio 
programming model rather then add generic "flexibility" features.