The implied background context is an analysis of whether C++ should adopt a fiber-based concurrency model <i>presuming</i> nothing outside a C++ compiler will ever change or be adapted. That may be a fair presumption from the perspective of the C++ committee, but the conclusions regarding efficiency and ergonomics of different concurrency models are not at all generalizable.<p>Even then, though, the analysis in the paper is still poor. Take section 2.2.1, for example:<p>> This is approach allows fibers to use very small stacks (less than a typical memory page size of 4K), but, at the cost that the developer must have complete knowledge of how big activation frames are for every function that can be called directly/transitively from the fiber. This is a very precarious approach to be used with extreme caution as the smallest mistake can lead to memory corruption and security exploits.<p>It characterizes the problem of determining stack size as being so intractable as to be unsafe. And yet this task--precisely calculating activation record size--is <i>exactly</i> what the compiler <i>must</i> <i>do</i> to implement stackless coroutines, the author's preferred solution (and the one adopted by Rust and eventually adopted by C++).<p>In reality, the compiler can't always do this, and so stackless coroutines in these languages don't permit things like recursive function invocations or calling through function pointers (e.g. virtual methods), at least not without falling back to dynamic heap allocation. And yet elsewhere in the paper the author discusses and dismisses segmented stacks, without it apparently occurring to the author that segmented stacks is precisely what a C++ stackless coroutine implementation must end up implementing in any call chain that cannot be statically determined, which can be quite a common (even pervasive) situation in an object oriented language or in environments with dynamic linking.
Response to "Fibers under the magnifying glass"
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0866r0.pdf" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p086...</a><p>Response to response to "Fibers under the magnifying glass"
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1520r0.pdf" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p152...</a>
I've certainly had situations where 'fibers' made more sense - a verilog runtime system with literally millions of them (where the compiler can figure out exactly how much space 99% of the fibers need - so stack sizes of 12 bytes, run-time contexts of similar sizes, 10 instruction dispatch times ....)
Ok, so I guess we can just completely ignore the countless lisp implementations with continuation support (which makes implementing fibers trivial).<p>"We looked at one programming language with fibers and it has poor performance when calling C." Is what I read in the last section.