If something in node is async, you have to wrap it up with _wrapAsync, else meteor explodes. Once it is wrapped, it is no longer async, your code will block until the (internal) callback is called, then it will continue.
It is exactly, not like a 'yield' in Twisted, that is the same in node, but in Meteor (server side) nearly everything is synchronous.
The readme explicitly even mentions that it yields:
https://github.com/laverdet/node-fibers/blob/master/README.m...
"Again, the node event loop is never blocked while this script is running."
This SO answer agrees:
http://stackoverflow.com/questions/10282828/node-js-modules-...
I don't remember what my test was, but I tried it, it doesn't block. Try to create something that you think doesn't block to freeze node while using fiber, it won't block, that's what makes fiber awesome. Fiber doesn't block. If you think it's blocking when it isn't it can kick your ass because you will assume incorrect order of events. It's just inline non-blocking.
If I'm wrong I would be happy to be corrected about this.
EDIT:
A perfect way to test this would be to loop through a bunch of HTTP requests that can take varying lengths of time to return and print when they finish, you're going to see they finish out of order. You'd have to write the loop such that each http request fires indepently of each other, which is tough in fiber, but a settimeout could do it (Checkout the sleep example in the fiber readme). If those http requests blocked other ones you'd have a pretty shitty situation, but they don't. And so if you assumed those HTTP requests completed in the same order you made them you would be in trouble.
I'm near 100% certain you are incorrect.
Additionally
=You can have it blocking per client too
This is useful since it ensures that requests from the client run in the order you intend (in case a method takes a while to respond)
You can get passed this by calling this.unblock() for that particular client only.
To clarify: This means it wont block other clients at all, unless the commands are blocking on a lower level (Filesystem IO for example)
But they do remove callbacks and thus asynchronity from libraries.
i.e aws-sdk
S3.putObject(..., function callback(result){})
result = S3.putObjectSync(...)
var x = 5;
x = S3.putObjectSync(...);
console.log(x);