HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
laverdet
node-fibers
C++2011–2018
laverdet / node-fibers

node-fibers

Fiber/coroutine support for v8 and node.

20Distinct people
24Mentions
0Explicit recommenders
3.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fiber/coroutine support for v8 and node.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year24 dated mentions

Observed mentions: 2011-03-24 15:18:31 UTC to 2018-06-06 21:53:07 UTC.

02468102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC615
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC10010
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
NOTE OF OBSOLESCENCE -- The author of this project recommends you avoid its use if possible. The original version of this module targeted nodejs v0.1.x in early 2011 when JavaScript on the server looked a lot different. Since then async/await, Promises, and Generators were standardized and the ecosystem as a whole has moved in that direction. I'll continue to support newer versions of nodejs as long as possible but v8 and nodejs are extraordinarily complex and dynamic platforms. It is inevitable that one day this library will abruptly stop working and no one will be able to do anything about it. I'd like to say thank you to all the users of fibers, your support over the years has meant a lot to me. Update [April 13th, 2021] -- Fibers is not compatible with nodejs v16.0.0 or later. Unfortunately, v8 commit dacc2fee0f is a breaking change and workarounds are non-trivial. fibers(1) -- Fiber support for v8 and Node Fibers, sometimes called coroutines, are a powerful tool which expose an API to jump between multiple call stacks from within a single thread. This can be useful to make code written for a synchronous library play nicely in an asynchronous environment. INSTALLING via npm npm install fibers You're done! (see "supported platforms" below if you run into errors) from source git clone git://github.com/laverdet/node-fibers.git cd node-fibers npm install Note: node-fibers uses node-gyp for building. To manually invoke the build process, you can use node-gyp rebuild. This will put the compiled extension in build/Release/fibers.node. However, when you do require('fibers'), it will expect the module to be in, for example, bin/linux-x64-v8-3.11/fibers.node. You can manually put the module here every time you build, or you can use the included build script. Either npm install or node build -f will do this for you. If you are going to be hacking on node-fibers, it may be worthwhile to first do node-gyp configure and then for subsequent rebuilds you can just do node-gyp build which will be faster than a full npm install or node-gyp rebuild. meteor users please read this If you're trying to get meteor running and you ended up at this page you're probably doing something wrong. Please uninstall all versions of NodeJS and Meteor, then start over. See meteor#5124 for more information. supported platforms If you are running 64-bit nodejs version 12.x or 14.x on Linux, OS X, or Windows (7 or later) then you should be able to install fibers from npm just fine. If you are running nodejs v10.x then you will need to use npm install fibers@4. Older versions of nodejs will require older and older version of fibers. (special thanks to Jeroen Janssen for his work on fibers in Windows) If you do end up needing to compile fibers first make sure you have node-gyp installed as a global dependency (npm install -g node-gyp), and that you have setup your build environment by following the instructions at node-gyp. Ubuntu-flavored Linux users may need to run sudo apt-get install g++ as well. EXAMPLES The examples below describe basic use of Fiber, but note that it is not recommended to use Fiber without an abstraction in between your code and fibers. See "FUTURES" below for additional information. Sleep This is a quick example of how you can write sleep() with fibers. Note that while the sleep() call is blocking inside the fiber, node is able to handle other events. $ cat sleep.js var Fiber = require('fibers'); function sleep(ms) { var fiber = Fiber.current; setTimeout(function() { fiber.run(); }, ms); Fiber.yield(); } Fiber(function() { console.log('wait... ' + new Date); sleep(1000); console.log('ok... ' + new Date); }).run(); console.log('back in main'); $ node sleep.js wait... Fri Jan 21 2011 22:42:04 GMT+0900 (JST) back in main ok... Fri Jan 21 2011 22:42:05 GMT+0900 (JST) Incremental Generator Yielding execution will resume back in the fiber right where you left off. You can also pass values back and forth through yield() and run(). Again, the node event loop is never blocked while this script is running. $ cat generator.js var Fiber = require('fibers'); var inc = Fiber(function(start) { var total = start; while (true) { total += Fiber.yield(total); } }); for (var ii = inc.run(1); ii <= 10; ii = inc.run(1)) { console.log(ii); } $ node generator.js 1 2 3 4 5 6 7 8 9 10 Fibonacci Generator Expanding on the incremental generator above, we can create a generator which returns a new Fibonacci number with each invocation. You can compare this with the ECMAScript Harmony Generator Fibonacci example. $ cat fibonacci.js var Fiber = require('fibers'); // Generator function. Returns a function which returns incrementing // Fibonacci numbers with each call. function Fibonacci() { // Create a new fiber which yields sequential Fibonacci numbers var fiber = Fiber(function() { Fiber.yield(0); // F(0) -> 0 var prev = 0, curr = 1; while (true) { Fiber.yield(curr); var tmp = prev + curr; prev = curr; curr = tmp; } }); // Return a bound handle to `run` on this fiber return fiber.run.bind(fiber); } // Initialize a new Fibonacci sequence and iterate up to 1597 var seq = Fibonacci(); for (var ii = seq(); ii <= 1597; ii = seq()) { console.log(ii); } $ node fibonacci.js 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 Basic Exceptions Fibers are exception-safe; exceptions will continue travelling through fiber boundaries: $ cat error.js var Fiber = require('fibers'); var fn = Fiber(function() { console.log('async work here...'); Fiber.yield(); console.log('still working...'); Fiber.yield(); console.log('just a little bit more...'); Fiber.yield(); throw new Error('oh crap!'); }); try { while (true) { fn.run(); } } catch(e) { console.log('safely caught that error!'); console.log(e.stack); } console.log('done!'); $ node error.js async work here... still working... just a little bit more... safely caught that error! Error: oh crap! at error.js:11:9 done!
Read the full README on GitHub

What Hacker News says

24 sources
Reminds me of `node-fibers`[1] var Fiber = require('fibers'); function sleep(ms) { var fiber = Fiber.current; setTimeout(function() { fiber.run(); }, ms); Fiber.yield(); } Fiber(function() { console.log('wait... ' + new Date); sleep(1000); console.log('ok... ' + new Date); }).run(); console.log('back in main'); It is used heavily in meteor[2] 1: https://github.com/laverdet/node-fibers 2: https://github.com/meteor/meteor
In Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
From their front page: > io.js is an npm compatible platform originally based on node.js™. Sorry, they were aiming for 100% tests passing [1], I would assume for npm compatibility which is their primary goal. A stable API means that dependent packages don't have to change to stay compatible. Tests are failing because they change things that broke packages: * Node-inspector does not work with io.js! How is anyone supposed to debug their code? [2] * Fibers do not work [3] * msgpack does not work [4] * sqlite3... there is a long list [5] There is no CI, no debugger, tests aren't passing, major modules don't work. I absolutely cannot go to my CEO and make a bet on that for my company. I think io.js is great! But the amount of misinformation about the state of Node is staggering. Let anyone with proof otherwise also cite their sources. [1
Read the rest
In Joyent Moves to Establish Node.js Foundation
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:
Read the rest
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.
In A JavaScript Primer For Meteor
I passionately hate XML so this could not possibly resonate with me. I never had the enlightenment he talks about. Actually I think that learning Lisp/Scheme might have made me a bit of a worse programmer in a way. It made me "dread" repetitive code so much to the point that I almost could not do anything with any language that's not highly dynamic. Anyways. I had 2 epiphanies with lisp. 1. Macros. Very powerful concept, but in practice difficult to use properly in your code. It's too difficult to reason about what's going on, like say, if you're maintaining or modifying a set of macros. I think it's more useful not as a construct that you would often use in your own code, but as a construct that's very useful for making libraries. 2. Continuations. This is not really related to lisp itself, and can be done in other languages, like javasc
Read the rest
ript[0]. Understanding a continuation as an even higher level construct than closures .. and the fact that scheme had it built-in was very mind blowing for me. It makes sense though that a lisp language must have it built-in. It's a concept that's very fundamental to the theory of computation, but in most programming languages it's not explicit at all. Before continuations, I thought no lisp language can ever have equivalents of "break", "return", or "continue". After understanding continuations, I see that these constructs can built using continuations as a basic building block. So this to me suggests that the concept of "continuation" is a very basic and fundamental concept that all students of Computer Science should be familiar with. Unfortunately I was never taught about it in University. [0]: https://github.com/laverdet/node-fibers
In The Nature of Lisp
Excellent talk. I'm really excited that somebody else besides me is advocating the cooperative switching async approach for other languages besides python with greenlet. I've been trying to get something going for JavaScript on top of spidermonkey, but it's been slow going. A few hacks are available in my github. Some of them use spidermonkey's generators to cooperate, and this approach will have the same drawbacks this approach has in python, but this hack with python-spidermonkey and greenlet is pretty sweet: https://github.com/fzzzy/js-actors python-spidermonkey is on a really old version of spidermonkey, unfortunately. Also, node-fibers looks totally sweet: https://github.com/laverdet/node-fibers Lua has coroutines built in, so I'm guessing this kind of stuff is common there. I haven't used lua much, though. Ruby also has cooperative
Read the rest
userland threads that could be used to implement a cooperative async lib. I always wondered why nobody did. I would have, if I had ever decided to get heavily into ruby.
In Distributed Systems with ZeroMQ and Gevent (Presentation)

Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.