Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: nodejs/node-v0.x-archive
base: 12dec40cf62e
Choose a base ref
...
head repository: nodejs/node-v0.x-archive
compare: ca744e4417b6
Choose a head ref
  • 3 commits
  • 6 files changed
  • 2 contributors

Commits on Feb 27, 2015

  1. test: make destroyed-socket-write2.js more robust

    test/simple/test-http-destroyed-socket-write2.js validates
    that you get an appropriate error when trying to write to
    a request when the response on the other side has been destroyed.
    
    The test uses http.request to get a request and then keeps writing
    to it until either it hits 128 writes or gets the expected error.
    Since the writes are asynchronous we see that the writes just end
    up adding events to the event loop, which then later get processed
    once the connection supporting the request is fully ready.
    
    The test is timing dependent and if takes too long for the connection
    to be made the limit of 128 writes is exceeded and the test fails.
    The fact that the test allows a number of writes is probably to allow
    some delay for the connection to be ready for writing.
    
    On AIX, in the default configuration using the loopback interface
    is slower and the test fails because the delay is such that many
    more writes can be queued up before the connection takes place.
    If we use the host ip instead of defaulting to the loopback then
    the test passes.
    
    The test needs to be made more robust to delays. Since each write
    simply enqueues an additional write to the event queue there is
    probably no point in doing the second write until the first has
    completed. This patch schedules the next write when the first one
    completes and allows the test to pass even if it takes longer for
    the connection to be ready for writing
    
    PR-URL: #9270
    Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
    Reviewed-By: Timothy J Fontaine <tjfontaine@gmail.com>
    mhdawson authored and cjihrig committed Feb 27, 2015
    Copy the full SHA
    3e40e12 View commit details
    Browse the repository at this point in the history
  2. src: fix builtin modules failing with --use-strict

    Currently, lib/_tls_legacy.js and lib/crypto.js cannot be loaded when
    --use-strict is passed to node. In addition to that, console.trace
    throws because it uses arguments.callee.
    
    This change fixes these issues and adds a test that makes sure
    every external built-in module can be loaded with require when
    --use-strict is enabled.
    
    Please note that this change does not fix all issues with built-in
    modules' code running with --use-strict. It is very likely that some
    code in the built-in modules still fails when passing this flag.
    
    However, fixing all code would require us to enable strict mode by
    default in all builtins modules, which would certainly break existing
    applications.
    
    Fixes #9187.
    
    Reviewed-By:
    PR-URL: #9237
    Julien Gilli committed Feb 27, 2015
    Copy the full SHA
    525423b View commit details
    Browse the repository at this point in the history
  3. tests: fix race in test-http-curl-chunk-problem

    Reviewed-By:
    PR-URL: #9237
    Julien Gilli committed Feb 27, 2015
    Copy the full SHA
    ca744e4 View commit details
    Browse the repository at this point in the history