Boost logo

Boost :

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:

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at