I only skimmed the article, but is the argument basically that fibers suck because library/DLL authors suck and use TLS instead of passing around an explicitly caller-initialized context pointer? So you can't freely use DLLs from your fibers because they might rely on TLS that isn't fibers-aware?
If so, that's a pretty weak argument. I use coroutines/fibers quite a bit in personal projects, but learned long ago for a variety of reasons to avoid depending on third party libraries I didn't have source for - especially ones that try to do too much magic like TLS behind the scenes just to save me the trouble of supplying an instance/context pointer to every call.
Usually when I'm using fibers it's so I can have many of them, which means I'm using tiny stack sizes, which means I'm not casually calling into third party libraries I can't easily audit and control anyways. If I weren't making many, I'd just use full-blown threads.
> especially ones that try to do too much magic like TLS behind the scenes just to save me the trouble of supplying an instance/context pointer to every call.
I really hate that this is the solution that Rust ended up pursuing. There are claims that you can work around TLS by just no using TLS if it is not available, but I have yet to see someone removing TLS and still be able to use a multi-threaded executor.
If so, that's a pretty weak argument. I use coroutines/fibers quite a bit in personal projects, but learned long ago for a variety of reasons to avoid depending on third party libraries I didn't have source for - especially ones that try to do too much magic like TLS behind the scenes just to save me the trouble of supplying an instance/context pointer to every call.
Usually when I'm using fibers it's so I can have many of them, which means I'm using tiny stack sizes, which means I'm not casually calling into third party libraries I can't easily audit and control anyways. If I weren't making many, I'd just use full-blown threads.