[boost] 'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context

Subject: [boost] 'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context
From: james (james_at_[hidden])
Date: 2017-10-15 10:31:30

I was considering whether I could/should build an actor system on Rust 
rather than C++, since it would be an interesting exercise for me.

And then I found this article:
https://www.reddit.com/r/rust/comments/56wgzq/status_of_coroutines/

In particular:
 > we noticed that the Rust stdlib is actually using TLS (!) to 
implement exceptions

It seems to me that in practice other compilers might use some sort of 
thread-local hook for exceptions, whether it is TLS or something 
lower-level that supports TLS.

And that the issue is whether the compiler will assume that the address 
of the TLS (or thread information block etc) is volatile, or can be 
cached in a stack frame or register across calls.

It seems to me that any such caching of an address might cause 
difficulty, not just in Rust but also other languages.  Microsoft's 
compiler explicitly has a switch for 'fibre safe optimisations' that 
disables such caching.

The worry I have is code like this:

void foo()
{
 Â  try { A() } catch (...) {}
 Â  B();Â  // Can switch the context to another underlying OS thread
 Â  try { C() } catch (...) {}
}

I am concerned that information about exception handling that was 
acquired for the first try block, might be retained in the frame and 
reused in the second try block.  and the information might be captured 
in the frame and/or registers that get saved in the context, but in an 
arbitrary way.

I suspect that access to explicit ABI TLS or C++ thread local is also 
impacted, although it might be easier to avoid.

I guess its not a complete show-stopper if we ensure that fibres never 
migrate between OS threads, but that is somewhat inconvenient.

So - is this actually a Rustc specific issue?