3 ms·
It is an OS component, it's provided in kernel32.dll and accesses internal OS data structures that are not publicly defined or stable between versions. You cann
by ack_complete 3y ago
It is an OS component, it's provided in kernel32.dll and accesses internal OS data structures that are not publicly defined or stable between versions. You cannot safely implement fibers in Windows without the fibers API, period. Boost.Context's direct Windows context switching code hacks undocumented fields in the TIB:
https://github.com/boostorg/context/blob/6fa6d5c50d120e69b2d8a1c0d2256ee933e94b3b/src/asm/jump_x86_64_ms_pe_masm.asm#L117 https://github.com/boostorg/context/blob/6fa6d5c50d120e69b2d...
...and this causes problems, because it can't guarantee that all fields are initialized or switched successfully: https://lists.boost.org/boost-bugs/2014/10/38476.php https://lists.boost.org/boost-bugs/2014/10/38476.php
Microsoft continually adds and changes fields in the TIB with each new release of Windows. Attempting to implement fibers manually is a ticking time bomb that should never be used in production.
- nickelpro 3y agoThat bug was caused by the TLS slots pointer being uninitialized in the newly created Boost fiber, not a change in Windows API. TLS pre-dates boost::context, the field had existed since the very first commit. I already said "MS would rather you not", obviously, otherwise they would have documented the TIB. The fact remains that tons of production systems rely on officially-unofficial elements of NT's architecture and this is one such element that is heavily relied on by everyone who uses boost stackful coroutines. Hyrum's Law in action.
- ack_complete 3y agoThe bug was caused by Boost.Context manipulating OS data structure fields that it has no business changing. And yes, those fields do now have to be maintained for backwards compatibility -- because libraries like Boost.Context hardcoded this into applications, unbeknownst to the users of that library.