Disallow thread local concepts to allow fibers move between threads @notl

[Richard (Rikki) Andrew Cattermole]

On 20/06/2024 7:11 AM, Sebastiaan Koppe wrote:
>     Might as well kick start the eventloop rewrite before we get
>     stackless coroutines.
> 
>     But that means fibers need to be made "safe" to move between threads.
> 
> I don't think the problem is with fibers per se. They can move between 
> threads just fine, and TLS variables continue to function as designed, 
> that is, they point to the thread local data of the thread the fiber 
> happens to be executing on.

With a fiber you have the unknown yield locations so the compiler cannot 
make guarantees regarding safety. But yes I noted that there is nothing 
stopping them from a technical perspective in my opening post.

> Rather, I believe the problem is with assumptions code makes when 
> (mis)using TLS data. To that end, can you give me an example of code ran 
> on fibers that needs to be made "safe"?

Yes its the assumption that is the problem, and those assumptions are 
very easy to make even for experienced developers (i.e. calling into a 
library that wasn't designed to be used from a stack(less) coroutine 
that can move between threads.

> Also, could it be you are trying to do too many things at once? 
> Salvaging eventcore, doing an eventloop, fibers /and/ stackless 
> coroutines? I see no reason why any of them need to be as coupled as 
> suggested.

I'm not sure what you mean by coupling here.

There is no point in improving vibe.d's eventloop support if nothing can 
take advantage of it.

I remember vibe.d was designed 12 years ago with the knowledge that 
fibers couldn't move between threads safely. This was a design 
constraint and this proposal alleviates it.

As for doing too much, I'm not comfortable with writing the DIP at the 
present point in time for stack less coroutines. The slicing and dicing 
of it and what it would take in compiler has unknown restrictions. Now 
if Walter were to tell me that it's too important to care about the 
complexity of implementation and I can do whatever and we'll figure it 
out eventually that would be a good thing to know.