Meteor._wrapAsync is one of the coolest things about Meteor. I didn't really understand its power until I watched EventedMind's video on it, though - https://www.eventedmind.com/feed/meteor-meteor-wrapasync.

I keep using it to keep my code clean and avoid callbackhell(.com).

It's just just inline non-blocking right? When people say "not async" I think blocking, but it's actually async in that you can have other operations happen in between execution of lines of code. Like if something that would traditionally be async in node executes, you don't have to wrap a callback in a function, yet it's still async, kind of like yield statements in python Twisted. If you think it isn't async and it is you're going to be in a world of hurt some day.

In meteor it is synchronous.

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.

I believe you're wrong, it's not blocking otherwise it would be terrible. I remember testing this before. Fibers is inline non-blocking.

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.

They don't block the event loop, no.

But they do remove callbacks and thus asynchronity from libraries.

i.e aws-sdk

    S3.putObject(..., function callback(result){})

would become (with _wrapAsync):

    result = S3.putObjectSync(...)

In the below example:

    var x = 5;
    x = S3.putObjectSync(...);
    console.log(x);

The console will never log "5". That is what I mean... maybe I'm confusing the terminology though :\

I believe you are right.

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)