3 ms·

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

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.md 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-async-vs-fibers-promise-vs-q-oper8 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.

Tarang 13y ago
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)
1stop 13y ago
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 :\

Tarang 13y ago

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)

1stop 13y ago

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 :\