Skip to content
Commits on Apr 8, 2013
  1. Merge pull request #107 from sdarnell/fls_fix2

    Find thread local slots using v8 isolate pointer (windows fix)
Commits on Apr 6, 2013
  1. @sdarnell

    Find thread local slots using v8 isolate pointer

    sdarnell committed
    Add __stdcall to correct declaration of find_thread_id().
    Then search back in the latest 20 slots for the v8 isolate pointer.
Commits on Apr 2, 2013
  1. dont short circuit tests

Commits on Apr 1, 2013
  1. commit

  2. commit

Commits on Mar 30, 2013
  1. Merge pull request #105 from metamatt/unhandled-exceptions

    Forward unhandled exceptions to main event loop
Commits on Mar 21, 2013
  1. @metamatt

    Forward unhandled exceptions to main event loop

    metamatt committed
    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()
    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
    Note that in conjunction with Future.wait(), the resolve callback will
    often be the local cb() function defined inside Future.wait() itself,
    which calls, 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 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.
  2. @metamatt

    Test for exceptions thrown in a future resolve callback,

    metamatt committed
    especially those thrown in a fiber which uses Future.wait,
    which has a nested deferred call to which causes
    such exceptions to land in the resolver for the previous wait.
    This currently exits the whole node process, and should not.
Commits on Jan 14, 2013
Commits on Jan 11, 2013
  1. Bump npm version -> 1.0.0

    - Fiber() is no longer global, use return value of require('fibers')
    - More robust stack limits
    - Fiber API is pretty much frozen
  2. Fix up Windows support

    libcoro now has a Windows Fiber backend, so we can remove the custom
    code that was handling that.
  3. Update stack limits

    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.
  4. Update libcoro to 1.67

Commits on Jan 6, 2013
  1. Remove global `Fiber` and `yield`

    Fixes gh-72
  2. Add check missing node-gyp

    Older versions of npm do not give you node-gyp, causing the build the
    fail. This is now detected and a better error is given.
    Fixes gh-96
  3. Fix crash in boundless recursion

    Fixes gh-89
Commits on Sep 2, 2012
  1. Bump npm version -> 0.6.9

    There's no code changes included in the jump from 0.6.8, just a
    recompilation for Linux, per gh-88.
Commits on Jun 24, 2012
  1. Seed random number before loading library

    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
  2. Bump npm version -> 0.6.8

  3. Distinct binaries for v8 versions

    node 0.8 brings in a new version of v8 which has binary incompatibility
    with existing extensions. We'll have to carry around different binaries
    for major v8 versions as well.
Commits on May 14, 2012
  1. Build fixes

    - Fix sunos
    - Reuse npm's node-gyp instead of pulling in our own copy
Commits on May 11, 2012
  1. Minor documentation updates

Commits on May 9, 2012
  1. Fix unit test issues on Windows

    None of these tests fail really on Windows.. they just had some bugs in
    the tests themselves.
  2. Don't rename node module for different archs

    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".
  3. Pure-JS test script

    This removes the last dependency on bash.
    Also fix a couple of issues with the npm package file.
  4. Port build to gyp + setup for binary distribution

    node-gyp powers building now, for all operating systems. Only Windows,
    Linux, and OS X were tested. arm support for Linux also was not tested.
    Also included is a wrapper module which pulls in a binary specific to
    your platform.
Commits on May 8, 2012
  1. Begin transition to non-global Fiber object

    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.
    var Fiber = require('fibers');
  2. Correct stack base calculations for Windows

    I can never get that math right in my head the first time. This should
    be correct and all the fibers tests pass fine in Windows now.
  3. Remove pool allocator for coroutine stacks

    There is little performance benefit here, if any. It also may be
    harmful, since the chunks of memory allocated are very large anyway.
    Since this is GNU-specific and complicates compilation on Windows, away
    it goes.
  4. @japj

    Tentative Windows support

    japj committed with
    Squashed commit of `winfiber` branch @
    This adds support for Windows. There's some issues but nothing that
    can't be fixed.
    Minor formatting issues changed (dangling tabs, spaces for tabs).
Commits on May 4, 2012
  1. Remove mtime check on fibers require()

    If there are problems with the build, they aren't going to be from
    upgrading Node. Plus I want to move to binary distribution soon if
    possible and this will be counterproductive.
  2. Use <node.h> instead of <node/node.h>

    Seems it is more standard and will make it easier for some people to
    get this installed.
Commits on Apr 27, 2012
  1. Bump npm version -> 0.6.6

Something went wrong with that request. Please try again.