DConf 2015 has ended. See you in Berlin at DConf 2016!

[Dan Olson via Digitalmars-d-announce]

Steven Schveighoffer <schveiguy at yahoo.com> writes:

> On 6/1/15 11:40 AM, Dan Olson wrote:
>> "Dicebot" <public at dicebot.lv> writes:
>>
>>> - Moving fibers between threads (though there is some hope that Liran
>>> managed to convince Walter it is a bad idea)
>>
>> I am interesting in this one.  What was the decision, that Fibers should
>> or should not be allowed to migrate between threads?  Is the discussion
>> in one of the recorded talks?
>>
>
> Walter said that fibers must be movable between threads, it was part
> of the AMA I think (day 1 final talk).

Just listened to it.  I would be interested to know applications
where migrating Fibers across threads is a good thing.  I can imagine
server load balancing over cores.  What else?

The issue I've been tripped up by with migrating Fibers is that compiler
backends like LLVM and GCC do some nice optimizations with thread-locals
on some targets that lead to incorrect code when a Fiber yields and
comes back on a different thread.  To get it right, the compiler would
have to assume that any function call could return on a different
thread.

The solutions I can think of today are to: not optimize (not a good
solution), or have a special compiler switch to not optimize TLS (not
available in backend), or ensure Fibers don't access TLS vars (not sure
how that could be done except by being careful), or don't migrate.
Inlining makes being careful difficult because a function call before
and after a yield may access the same TLS var, and compiler then decides
to cache the TLS address in a register.

I have been prototyping a Fiber check that throws an exception on
targets with this issue, and the developer can override it by setting a
Fiber property, after promising to be careful.

http://forum.dlang.org/thread/onkyxucuuthaqxxbkoir@forum.dlang.org#post-m2d223wqa0.fsf:40comcast.net