Lets talk about fibers

[Jonathan M Davis via Digitalmars-d]

On Thursday, 4 June 2015 at 13:16:48 UTC, Steven Schveighoffer 
wrote:
> On 6/3/15 9:51 PM, 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.
>
> I plead complete ignorance and inexperience with fibers and 
> thread scheduling.
>
> But I think the sanest approach here is to NOT support moving 
> fibers, and then add support if it becomes necessary. We can 
> make the scheduler something that's parameterized, or hell, 
> just edit your own runtime if you need it!
>
> It may also be that fibers that move can't be statically 
> checked to see if they will break on moving. That may simply 
> just be on you, like casting.
>
> I think for the most part, the safest default is to have a 
> fiber scheduler that cannot possibly create races. Let's build 
> from there.

One thing that needs to be considered that deadalnix pointed out 
at dconf is that we _do_ have shared(Fiber), and we have to deal 
with that in some manner, even if we don't want to support moving 
fibers across threads (even if that simply means disallowing 
shared(Fiber)).

- Jonathan M Davis