3 ms·

It uses Fibers (https://github.com/laverdet/node-fibers https://github.com/laverdet/node-fibers). I don't know much about it, but you have to wrap all your code

by tg3 13y ago

It uses Fibers (https://github.com/laverdet/node-fibers https://github.com/laverdet/node-fibers). I don't know much about it, but you have to wrap all your code in a call to `Fiber()`, which is written in C++.

lucio 13y ago
Fiber() is under the hood, and I hope ES6 generators -when stable- will provide similar tools, so wait.for could be based on ES6 generators. You don't have to wrap all your code in a call to `Fiber()` full classic node-server sample: var http=require('http'), wait=require('wait.for'); http.createServer(function(req, res) { wait.launchFiber(handleRequest,req, res); //run in a Fiber, keep node spinning }).listen(8080); //in a fiber function handleRequest(req, res) { try { res.writeHead(200, {'Content-Type': 'text/html'}); res.end( "<h1>Demo page</h1>" + "<p>"+ wait.for(fs.readFile,'/etc/somefile') +"</p>" + "<p>"+ wait.for(fs.readFile,'/etc/otherfile') +"</p>"); } catch(err) { res.end('error '+e.message); } }
- tg3 13y ago
  in your example below, you do have to wrap it in a call to `Fiber()`, although you've disguised it as `launchFiber`, which you pass `handleRequest` to (I would call that wrapping `handleRequest`. That is probably a worthwhile tradeoff, but the first time I read through it, that mechanic wasn't obvious to me.
  - lucio 13y ago
    It's not 'disguised', it's abstracted. launchFiber does what it's name implies: launchs a fiber. How it is achieved 'internally', it's irrelevant as long the abstraction is not leaky. Today launchFiber is calling the fn inside a Fiber(), tomorrow could be launching the fiber by means of a generator. The idea was to create a very simple abstraction to avoid callback hell, adding low or no complexity, and keeping the flexibility to use all the existing async fns with a callback or just "wait" for the results.

by tg3 13y ago

lucio 13y ago

Fiber() is under the hood, and I hope ES6 generators -when stable- will provide similar tools, so wait.for could be based on ES6 generators. You don't have to wrap all your code in a call to `Fiber()` full classic node-server sample: var http=require('http'), wait=require('wait.for'); http.createServer(function(req, res) { wait.launchFiber(handleRequest,req, res); //run in a Fiber, keep node spinning }).listen(8080); //in a fiber function handleRequest(req, res) { try { res.writeHead(200, {'Content-Type': 'text/html'}); res.end( "<h1>Demo page</h1>" + "<p>"+ wait.for(fs.readFile,'/etc/somefile') +"</p>" + "<p>"+ wait.for(fs.readFile,'/etc/otherfile') +"</p>"); } catch(err) { res.end('error '+e.message); } }

tg3 13y ago
in your example below, you do have to wrap it in a call to `Fiber()`, although you've disguised it as `launchFiber`, which you pass `handleRequest` to (I would call that wrapping `handleRequest`. That is probably a worthwhile tradeoff, but the first time I read through it, that mechanic wasn't obvious to me.
- lucio 13y ago
  It's not 'disguised', it's abstracted. launchFiber does what it's name implies: launchs a fiber. How it is achieved 'internally', it's irrelevant as long the abstraction is not leaky. Today launchFiber is calling the fn inside a Fiber(), tomorrow could be launching the fiber by means of a generator. The idea was to create a very simple abstraction to avoid callback hell, adding low or no complexity, and keeping the flexibility to use all the existing async fns with a callback or just "wait" for the results.