Fibers, Oh My (2020) | Hacker News Reader

Fibers, Oh My (2020)

graphitemaster.github.io

51 pointsmv913 comments

> What if our fibers invoke operating system primitives that block, or interfaces which indirectly do?

The best fiber interfaces, like virtual threads in Java, intercept these blocking primitives and perform the yield there implicitly. This means that user code just doesn't need to worry about this at all and can block as they normally would.

Same with go.

And Node.js

Parts of this, especially the first few chapters, sound very similar to what I wrote earlier that year (and have then kept updating for another year):

https://github.com/slouc/concurrency-in-scala-with-ce

I also later distilled it into this one:

https://slouc.com/Fibers/

Would be fun to believe that something I wrote inspired parts of this one, but in reality it's probably just a case of great minds thinking (and sounding) alike :)

Anyway, I'm glad to have found this great text. I agree with the author's statement that "there’s a distinctive lack of good information online", because I felt the same way writing mine. Thanks hn and whoever (re)posted this.

Discussed at the time:

Fibers, Oh My - https://news.ycombinator.com/item?id=24679740 - Oct 2020 (69 comments)

(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)

> This means it’s not possible to race data, dead lock, live lock, etc. While this statement is true when you look at fibers as a N:1 proposition

Deadlocks are still possible when using fibers backed by a single thread if you serialize your fiber execution. Here’s an example I’ve seen in the wild:

Imagine a serialized job server implemented with fibers that, when closed, waits for all jobs to finish by posting a final bookend job and waiting for it to finish. This works, unless you decide to close the server inside one of your serialized jobs—you’ve now created a deadlock where your job server is waiting for itself to finish closing.

I’m sure an N:1 deadlock is also possible without serialization, but I can only think of contrived examples.

I worked on a fiber-based backend once. had fun also with mmaps and signals. lots of low-level Linux optimizations and edge case 9's pursuit.

Ditto (we had hand-rolled a coroutine system implemented in the most pedestrian manner you could imagine). Compared to the usual sea-of-threads and all the synchronization hell that falls out of that, a coroutine-based system was absolutely magical. Vastly fewer threading bugs.

Being able to meaningfully support 500K users on a single mid-grade server was also great for the pocketbook. (When I saw the sheer scale of the Twitter servers a while back, I was gasping for air).

I hear you. certain locking or date race issues just.. go away :-)

> It is possible for multiple OS threads to be running in parallel with symmetric multiprocessing (SMP)

Why does the author say "possible"? Isn't it basically always the case that a modern computer is running as many threads in parallel as it has cores?

I'm not sure what's your point, single threaded CPUs exist.

Hi, I think English isn't your first language so, first, let me point out that telling someone "I'm not sure what your point is" comes across as rude and aggressive.

I wasn't "making a point". I was asking a question. My question is why the author said "possible": since this is an educational piece of writing, isn't it misleading to say "possible"? Am I right in thinking that basically all computers in common use now (e.g. phones, laptops, desktops, machines used in corporate data centers) have multiple CPU cores? And furthermore, that they are basically always executing instructions simultaneously on all cores? (Instructions from some userspace process or the kernel)

Meh, their engine scalability was/is a disaster on PC. Especially as far as CPUs are concerned. IdTech 7 is where it's at. 500fps+ of goodness... give it what you have, it will take all of your cores, every single one, and run even faster.

Reply on news.ycombinator.com