Libuv may provide a NULL buffer to the uv_read callback in case of an
error, so with this assert we'd be using the api incorrectly. None of
the current DoRead implementations rely on this constraint, either.
The console module has always been called 'stdio' in the
table-of-contents, but nowhere else, since its name is
'console'. This makes it difficult to find.
Resolves minor discrepancies between android and standard POSIX systems.
In addition, some configure parameters were added, and a helper-script
for android configuration. Ideally, this script should be merged into
the standard configure script.
To build for android, source the android-configure script with an NDK
path:
source ./android-configure ~/android-ndk-r8d
This will create an android standalone toolchain and export the
necessary environment parameters.
After that, build as normal:
make -j8
After the build, you should now have android-compatible NodeJS binaries.
Suppress the following warning:
../../src/cares_wrap.cc: In function ‘v8::Handle<v8::Value>
node::cares_wrap::SetServers(const v8::Arguments&)’:
../../src/cares_wrap.cc:1017:5: warning: ‘uv_ret.uv_err_s::code’
may be used uninitialized in this function [-Wuninitialized]
Split `tls.js` into `_tls_legacy.js`, containing legacy
`createSecurePair` API, and `_tls_wrap.js` containing new code based on
`tls_wrap` binding.
Remove tests that are no longer useful/valid.
In case of cross-compilation host_arch_cc() function could return
target arch if CC was set to target arch compiler. Host arch
compiler should always be used in this case. This was broken
by commit 707863c.
This reverts commit a40133d10c.
Unfortunately, this breaks socket.io. Even though it's not strictly an
API change, it is too subtle and in too brittle an area of node, to be
done in a stable branch.
Conflicts:
doc/api/http.markdown
When large strings are used they cause v8's GC to spend a lot more time
cleaning up. In these cases it's much faster to use external string
resources.
UTF8 strings do not use external string resources because only one and
two byte external strings are supported.
EXTERN_APEX is the value at which v8's GC overtakes performance.
The following table has the type and buffer size that use to encode the
strings as rough estimates of the percentage of performance gain from
this patch (UTF8 is missing because they cannot be externalized).
encoding 128KB 1MB 5MB
-----------------------------
ASCII 58% 208% 250%
HEX 15% 74% 86%
BASE64 11% 74% 71%
UCS2 2% 225% 398%
BINARY 2234% 1728% 2305%
BINARY is so much faster across the board because of using the new v8
WriteOneByte API.
v8 has a new API to write out strings to memory. This has been
implemented.
One other change of note is BINARY encoded strings have a new
implementation. This has improved performance substantially.