That was the response I got to my SO question:
I’m reposting this question because I’m determined to get an answer. Does fibers mimic threads or not? How does this.unblock() work?
The bull poop line is apparently this: “In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node.”
I think this article explains fibers, and how they fit into Meteor, really well.
Fibers provides an abstraction layer for the Event Loop that allows us to execute functions (tasks) in sequence. It allows us to write asynchronous code without callbacks. We get the best of both worlds–asynchronous efficiency with synchronous-style coding. Behind the scenes, Fibers takes care of dealing with the Event Loop.
Source: https://meteorhacks.com/fibers-eventloop-and-meteor
As for the comment, well it’s still true that Meteor code runs in a single thread (because Node.js) and that it’s anti-callback so I wouldn’t say it was pure bull poop 
No offense but that’s probably not really a problem with Meteor, because you’re looking at fibers. Fibers is a node package. You probably want to look into this.
Checkout these videos:
(free)
(I think these are pay-only with a preview)
No offence but I didn’t say there was a problem with Meteor. I was
interested in understanding how things work, and a specific line of the
meteor documentation.
@TwinTails - I’ve read the MeteorHacks article.
@SkinnyGeek1010 - I’ve watched the free EventedMind videos too.
I get the fact that Fibers allows us to write asynchronous code in a synchronous manner. I still don’t get how this.unblock() works, or this line of the docs:
In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node.
Documentation for this.unblock:
this.unblock - Call inside a method invocation. Allow subsequent method from this client to begin running in a new fiber.
On the server, methods from a given client run one at a time. The N+1th invocation from a client won’t start until the Nth invocation returns. However, you can change this by calling this.unblock. This will allow the N+1th invocation to start running in a new fiber.
If I still haven’t been clear enough, what happens when this.unblock is called and there’s a long computation after it. Can another request be dealt with at this time? Or would this.unblock only help methods that make an I/O request, and then as in regular Node.js, another request is dealt with while the I/O is happening?