'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context
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?
participants (1)
-
james