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.
