While walking the list of resolve callbacks and calling them, if something throws an exception, use process.nextTick() to rethrow the exception from the main event loop. The reason to catch such exceptions at all is because they're in client-provided code, and so the fiber-futures library shouldn't get blamed for them. The correct destination for such exceptions is the uncaughtException handler, and that's what rethrowing the exception fron nextTick() achieves. The previous behavior was to call process.exit() if such an exception should happen. That's too severe, however; exceptions in a resolve callback should be no more or less illegal than exceptions anywhere else. Note that in conjunction with Future.wait(), the resolve callback will often be the local cb() function defined inside Future.wait() itself, which calls fiber.run(), which propagates any exceptions that should happen inside the body of the fiber itself: this means it is actually completely normal for any exceptions that happen inside fiber client code to land (through fiber.run() and wait()'s cb() routine) in these callback processing routines' exception handlers. I don't know whether it's preferable to log the exception at the point we rethrow it or not. Mostly it will be unwelcome spew, but occasionally it could be vitally helpful. Also, such logging causes the new test for this change to fail, because tests in the fibers testsuite are supposed to print nothing more than "pass" to pass. As a compromise for discussion I've left the log statement present but commented out.
especially those thrown in a fiber which uses Future.wait, which has a nested deferred call to Fiber.run which causes such exceptions to land in the resolver for the previous wait. This currently exits the whole node process, and should not.
By default Fibers used to have a stack limit of 64k with 2k padding for v8's native code. This was problematic because some v8 code can use at least 240k of stack not even including the stack space client JS uses. The new limits are 512k/1M per fiber with 128k/256k padding. Additionally this implements libcoro's new stack management interface.
For some reason on Windows the random number generators gets seeded with the same thing every time if you load fibers. I didn't look into what causes this because we can easily fix it by generating a random number before loading the library. Perhaps I will look into the root cause eventually.. Fixes gh-82
Turns out you can't load a module on Windows that has been renamed from what it was called in the dllexport. So if you have fibers.node, and rename it to fibers2.node, `require('fibers2') will fail with "unknown error". I'm not sure if this is an inherent problem with dynamic libraries in Windows or just Node being pedantic. As a workaround just make a new directory for each platform and arch with only one file, "fibers.node".
This makes it so that require('fibers') returns the Fiber() object directly. I'll leave the global exporting for a while for library authors to convert and then remove it. Old: require('fibers'); Fiber(...); New: var Fiber = require('fibers'); Fiber(...);