Fiber in C++: Understanding the Basics
agraphicsguynotes.com
Fiber in C++: Understanding the Basics
1–10 of 77 posts
Re: Fiber in C++: Understanding the Basics
#2Still looking for a lib that supports fibers... boost::asio is... well, boost, and therefore annoying. It also does not support it out of the box
Re: Fiber in C++: Understanding the Basics
#3I'm confused in how this article defines "fiber." At the beginning of the article, fibers are described as a lightweight userspace thread, similar to what is provided in the runtimes of Haskell and Go, and has been recently revived in Java as "virtual threads."
However, later in the article (after a long and apparently irrelevant digression about stack management), they describe Windows API functions that are required for using fibers and seem to suggest that fibers are OS-level, and not application-managed.
Am I missing something?
[edit: typo]
Re: Fiber in C++: Understanding the Basics
#4Again, academia and the tech press overlook to talk about Actors, and we live in a world with poorly implemented pretend Actor subsets, without any of the true Actor features (work stealing, message passing etc, and best of all, no contention since no shared resources, other than Actor references).
Fibres, goroutines, promises, futures, job queues, etc, are poor substitutes for Actors.
Re: Fiber in C++: Understanding the Basics
#5Again, academia and the tech press overlook to talk about Actors, and we live in a world with poorly implemented pretend Actor subsets, without any of the true Actor features (work stealing, message passing etc, and best of all, no contention since no shared resources, other than Actor references). Fibres, goroutines, promises, futures, job queues, etc, are poor substitutes for Actors.
[deleted]
Re: Fiber in C++: Understanding the Basics
#6I'm confused in how this article defines "fiber." At the beginning of the article, fibers are described as a lightweight userspace thread, similar to what is provided in the runtimes of Haskell and Go, and has been recently revived in Java as "virtual threads." However, later in the article (after a long and apparently irrelevant digression about stack management), they describe Windows API functions that are require…
My general understanding is that a fiber is a lightweight thread, and conceptually can be implemented inside any program that wants to schedule its own fibers.
They’re distinct from CPU threads.
When I last dived into fibers I discovered windows was trying to make them a thing quite a while ago which is why we have things like [0].
Fibers being virtual threads, are recursive. In the same way you can run a VM inside a VM, you could build fibers on top of fibers (which sounds like a recipe for unpredictable performance).
[0] https://learn.microsoft.com/en-us/windows/win32/procthread/u...
Re: Fiber in C++: Understanding the Basics
#7I'm confused in how this article defines "fiber." At the beginning of the article, fibers are described as a lightweight userspace thread, similar to what is provided in the runtimes of Haskell and Go, and has been recently revived in Java as "virtual threads." However, later in the article (after a long and apparently irrelevant digression about stack management), they describe Windows API functions that are require…
Windows has its own fibers facility which does some things for you but still leaves the scheduling to the application so it's still fibers. It's a little confusing in the article but they look at the Windows API as a kind of API template - what do you need to implement to have fibers. Then they describe their own implementation.
Re: Fiber in C++: Understanding the Basics
#8Again, academia and the tech press overlook to talk about Actors, and we live in a world with poorly implemented pretend Actor subsets, without any of the true Actor features (work stealing, message passing etc, and best of all, no contention since no shared resources, other than Actor references). Fibres, goroutines, promises, futures, job queues, etc, are poor substitutes for Actors.
> Fibres, goroutines, promises, futures, job queues, etc, are poor substitutes for Actors.
They are not necessarily substitutes, they are lower level primitives that allow more complex models, like Actors, to be implemented.
All execution models have trade offs; and sometimes we might prefer an execution model without deadlock, livelock and starvation. So for a general purpose language, a complex model like Actors is ideally a library and not enforced as the only way of achieving concurrency.
Re: Fiber in C++: Understanding the Basics
#9I'm confused in how this article defines "fiber." At the beginning of the article, fibers are described as a lightweight userspace thread, similar to what is provided in the runtimes of Haskell and Go, and has been recently revived in Java as "virtual threads." However, later in the article (after a long and apparently irrelevant digression about stack management), they describe Windows API functions that are require…
Fiber is a concept in Windows API for user-space thread.
It was designed for MS SQL Server. It have a very confusing API and did not gain much use in 3rd party applications.
Re: Fiber in C++: Understanding the Basics
#10Again, academia and the tech press overlook to talk about Actors, and we live in a world with poorly implemented pretend Actor subsets, without any of the true Actor features (work stealing, message passing etc, and best of all, no contention since no shared resources, other than Actor references). Fibres, goroutines, promises, futures, job queues, etc, are poor substitutes for Actors.
No shared resources can be a performance problem, I can see why there are rusts and vales efforts to come to a slightly different tradeoff.