0

I've been recently dealing with Meteor (kind of legacy) code. I know the backend code makes (type wise) blocking calls to Mongo, but I have been told these calls work on fibers. From what I've seen these code running on fibers looks exactly the same as blocking code. I've been told it's ok, but I want to know how that's achieved. I come from a Scala background and I know fibers need some kind of suspending mechanism that allows computations to stand by until some result becomes available. That's not possible in classical blocking code. (In the case of Scala, flatmap separates computation from callback)

In other words... What does Meteor.bindEnvironment do?

That could be possible using async/await, or generators/yield.. but other than that? How? How do meteor fibers work? How can they avoid blocking the only available thread when making I/O operations like HTTP or using the file system?

caeus
  • 3,084
  • 1
  • 22
  • 36

1 Answers1

2

Meteor was designed in a time where callback hell so they opted for fibers to make building application much more simple with synchronous looking code. The Meteor fibers implementation is based on node-fibers which is no longer supported as of nodejs v16.0.0, that's why Meteor is attempting to replace fiber stuff with async/await and async hooks.

If you'd like to know more about how fibers stuff work within Meteor, I'd recommend Ben Newman talk and slides. And this answer too.

Harry Adel
  • 1,238
  • 11
  • 16
  • 1
    Just one note, it will be replaced with async/await and [async-hooks](https://nodejs.org/api/async_hooks.html) – Jankapunkt Nov 14 '21 at 10:49