This commit adds includes for node_internal.h in source files that use
arraysize but don't include this header. The motivation for this is to
make refactoring easier (and is the reason I noticed this).
PR-URL: https://github.com/nodejs/node/pull/19916
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Simply always tell the caller how many bytes were written, rather
than letting them track it.
In the case of writing a string, also keep track of the bytes
written by the earlier `DoTryWrite()`.
Refs: https://github.com/nodejs/node/issues/19562
PR-URL: https://github.com/nodejs/node/pull/19551
Reviewed-By: James M Snell <jasnell@gmail.com>
Move tracking of `socket.bytesWritten` to C++ land.
This makes it easier to provide this functionality for all
`StreamBase` instances, and in particular should keep working
when they have been 'consumed' in C++ in some way (e.g. for
the network sockets that are underlying to TLS or HTTP2 streams).
Also, this parallels `socket.bytesRead` a lot more now.
PR-URL: https://github.com/nodejs/node/pull/19551
Reviewed-By: James M Snell <jasnell@gmail.com>
Put `HandleScope`s and `Context::Scope`s where they are used,
and don’t create one for native stream callbacks automatically.
This is slightly less convenient but means that stream listeners
that don’t actually call back into JS don’t have to pay the
(small) cost of setting these up.
PR-URL: https://github.com/nodejs/node/pull/18936
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
`async` and `bytes` are only interesting when the write
is coming from JS, and unnecessary otherwise.
Also, make all of the stream `Write*()` bindings use the same
code for setting these, and upgrade to the non-deprecated versions.
PR-URL: https://github.com/nodejs/node/pull/18963
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Encapsulate stream requests more:
- `WriteWrap` and `ShutdownWrap` classes are now tailored to the
streams on which they are used. In particular, for most streams
these are now plain `AsyncWrap`s and do not carry the overhead
of unused libuv request data.
- Provide generic `Write()` and `Shutdown()` methods that wrap
around the actual implementations, and make *usage* of streams
easier, rather than implementing; for example, wrap objects
don’t need to be provided by callers anymore.
- Use `EmitAfterWrite()` and `EmitAfterShutdown()` handlers to
call the corresponding JS handlers, rather than always trying
to call them. This makes usage of streams by other C++ code
easier and leaner.
Also fix up some tests that were previously not actually testing
asynchronicity when the comments indicated that they would.
PR-URL: https://github.com/nodejs/node/pull/18676
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Instead of passing along the handle object, just set it as a
property on the stream handle object and let the read handler
grab it from there.
PR-URL: https://github.com/nodejs/node/pull/18334
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Instead of setting individual callbacks on streams and tracking
stream ownership through a boolean `consume_` flag, always have
one specific listener object in charge of a stream, and call
methods on that object rather than generic C-style callbacks.
PR-URL: https://github.com/nodejs/node/pull/18334
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Tests are passing without it, and this otherwise makes the
code harder to reason about because the `async` flag on the
write request object would not be set even though the callback
would still be pending.
PR-URL: https://github.com/nodejs/node/pull/18019
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Previously the getter would mutate the kDefaultTriggerAsncId value. This
refactor changes the setter to bind the current kDefaultTriggerAsncId to
a scope, such that the getter doesn't have to mutate its own value.
PR-URL: https://github.com/nodejs/node/pull/17273
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
rename initTriggerId to defaultTriggerAsyncId such it matches the rest
of our naming.
PR-URL: https://github.com/nodejs/node/pull/17273
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently, writeQueueSize is never used in C++ and barely used
within JS. Instead of constantly updating the value on the JS
object, create a getter that will retrieve the most up-to-date
value from C++.
For the vast majority of cases though, create a new prop on
Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this
to track the current write size, entirely in JS land.
PR-URL: https://github.com/nodejs/node/pull/17650
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This should make these function calls a lot more intuitive for people
who are more accustomed to Node’s EventEmitter API.
PR-URL: https://github.com/nodejs/node/pull/17701
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Instead of having per-request callbacks, always call a callback
on the `StreamBase` instance itself for `WriteWrap` and `ShutdownWrap`.
This makes `WriteWrap` cleanup consistent for all stream classes,
since the after-write callback is always the same now.
If special handling is needed for writes that happen to a sub-class,
`AfterWrite` can be overridden by that class, rather than that
class providing its own callback (e.g. updating the write
queue size for libuv streams).
If special handling is needed for writes that happen on another
stream instance, the existing `after_write_cb()` callback
is used for that (e.g. custom code after writing to the
transport from a TLS stream).
As a nice bonus, this also makes `WriteWrap` and `ShutdownWrap`
instances slightly smaller.
PR-URL: https://github.com/nodejs/node/pull/17564
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Squashed from multiple commits:
- src: replace ->To*(isolate) with ->To*(context).ToLocalChecked()
- test: use .As<Object> on Exception::Error
> Exception::Error always returns an object, so e.As<Object>() should also work fine
See https://github.com/nodejs/node/pull/17343#discussion_r153232027
- test: use .As<Object> instead of ->ToObject
we already checked that its a buffer
- src: use FromMaybe instead of ToLocalChecked
It fixed this test case: 19a1b2e414
- src: pass context to Get()
Dont pass Local<Context> is deprecated soon.
So we migrate to maybe version.
- src: return if Get or ToObject return an empty before call ToLocalChecked
Refs: https://github.com/nodejs/node/issues/17244
PR-URL: https://github.com/nodejs/node/pull/17343
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
This should help clarify what kind of resource a `StreamWrap`
represents.
PR-URL: https://github.com/nodejs/node/pull/16157
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
At long last: The initial *experimental* implementation of HTTP/2.
This is an accumulation of the work that has been done in the nodejs/http2
repository, squashed down to a couple of commits. The original commit
history has been preserved in the nodejs/http2 repository.
This PR introduces the nghttp2 C library as a new dependency. This library
provides the majority of the HTTP/2 protocol implementation, with the rest
of the code here providing the mapping of the library into a usable JS API.
Within src, a handful of new node_http2_*.c and node_http2_*.h files are
introduced. These provide the internal mechanisms that interface with nghttp
and define the `process.binding('http2')` interface.
The JS API is defined within `internal/http2/*.js`.
There are two APIs provided: Core and Compat.
The Core API is HTTP/2 specific and is designed to be as minimal and as
efficient as possible.
The Compat API is intended to be as close to the existing HTTP/1 API as
possible, with some exceptions.
Tests, documentation and initial benchmarks are included.
The `http2` module is gated by a new `--expose-http2` command line flag.
When used, `require('http2')` will be exposed to users. Note that there
is an existing `http2` module on npm that would be impacted by the introduction
of this module, which is the main reason for gating this behind a flag.
When using `require('http2')` the first time, a process warning will be
emitted indicating that an experimental feature is being used.
To run the benchmarks, the `h2load` tool (part of the nghttp project) is
required: `./node benchmarks/http2/simple.js benchmarker=h2load`. Only
two benchmarks are currently available.
Additional configuration options to enable verbose debugging are provided:
```
$ ./configure --debug-http2 --debug-nghttp2
$ NODE_DEBUG=http2 ./node
```
The `--debug-http2` configuration option enables verbose debug statements
from the `src/node_http2_*` files. The `--debug-nghttp2` enables the nghttp
library's own verbose debug output. The `NODE_DEBUG=http2` enables JS-level
debug output.
The following illustrates as simple HTTP/2 server and client interaction:
(The HTTP/2 client and server support both plain text and TLS connections)
```jt client = http2.connect('http://localhost:80');
const req = client.request({ ':path': '/some/path' });
req.on('data', (chunk) => { /* do something with the data */ });
req.on('end', () => {
client.destroy();
});
// Plain text (non-TLS server)
const server = http2.createServer();
server.on('stream', (stream, requestHeaders) => {
stream.respond({ ':status': 200 });
stream.write('hello ');
stream.end('world');
});
server.listen(80);
```
```js
const http2 = require('http2');
const client = http2.connect('http://localhost');
```
Author: Anna Henningsen <anna@addaleax.net>
Author: Colin Ihrig <cjihrig@gmail.com>
Author: Daniel Bevenius <daniel.bevenius@gmail.com>
Author: James M Snell <jasnell@gmail.com>
Author: Jun Mukai
Author: Kelvin Jin
Author: Matteo Collina <matteo.collina@gmail.com>
Author: Robert Kowalski <rok@kowalski.gd>
Author: Santiago Gimeno <santiago.gimeno@gmail.com>
Author: Sebastiaan Deckers <sebdeckers83@gmail.com>
Author: Yosuke Furukawa <yosuke.furukawa@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/14239
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/13174
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Changes in the native code for the upcoming async_hooks module. These
have been separated to help with review and testing.
Changes include:
* Introduce an async id stack that tracks recursive calls into async
execution contexts. For performance reasons the id stack is held as a
double* and assigned to a Float64Array. If the stack grows too large
it is then placed in it's own stack and replaced with a new double*.
This should accommodate arbitrarily large stacks.
I'm not especially happy with the complexity involved with this async
id stack, but it's also the fastest and most full proof way of
handling it that I have found.
* Add helper functions in Environment and AsyncWrap to work with the
async id stack.
* Add AsyncWrap::Reset() to allow AsyncWrap instances that have been
placed in a resource pool, instead of being released, to be
reinitialized. AsyncWrap::AsyncWrap() also now uses Reset() for
initialization.
* AsyncWrap* parent no longer needs to be passed via the constructor.
* Introduce Environment::AsyncHooks class to contain the needed native
functionality. This includes the pointer to the async id stack, and
array of v8::Eternal<v8::String>'s that hold the names of all
providers, mechanisms for storing/retrieving the trigger id, etc.
* Introduce Environment::AsyncHooks::ExecScope as a way to track the
current id and trigger id of function execution via RAII.
* If the user passes --abort-on-uncaught-exception then instead of
throwing the application will print a stack trace and abort.
PR-URL: https://github.com/nodejs/node/pull/12892
Ref: https://github.com/nodejs/node/pull/11883
Ref: https://github.com/nodejs/node/pull/8531
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Turn a `CHECK()` that could be brought to fail using public APIs
into throwing an error.
Fixes: https://github.com/nodejs/node/issues/12152
PR-URL: https://github.com/nodejs/node/pull/12753
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Always use `req_wrap_obj` to allow calling `req->Done()` in stream
implementations.
PR-URL: https://github.com/nodejs/node/pull/10184
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
instead of creating own buffer, use MaybeStackBuffer on DoSend to
take advantage of its destructor to free up memory, so buffer
never leaks memory - even if code in DoSend throws.
Use MaybeStackBuffer in Writev to take advantage of destructor
on MaybeStackBuffer to clear itself up, rather than Writev managing
resources itself.
PR-URL: https://github.com/nodejs/node/pull/8626
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Set the `req.buffer` property, which serves as a way of keeping
a `Buffer` alive that is being written to a stream, on the C++
side instead of the JS side.
This closes a hole where buffers that were temporarily created
in order to write strings with uncommon encodings (e.g. `hex`)
were passed to the native side without being set as `req.buffer`.
Fixes: https://github.com/nodejs/node/issues/8251
PR-URL: https://github.com/nodejs/node/pull/8252
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When node began using the OneByte API (f150d56) it also switched to
officially supporting ISO-8859-1. Though at the time no new encoding
string was introduced.
Introduce the new encoding string 'latin1' to be more explicit. The
previous 'binary' and documented as an alias to 'latin1'. While many
tests have switched to use 'latin1', there are still plenty that do both
'binary' and 'latin1' checks side-by-side to ensure there is no
regression.
PR-URL: https://github.com/nodejs/node/pull/7111
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
v8::Object::GetAlignedPointerFromInternalField() returns a random value
if Wrap() hasn't been run on the object handle. Causing v8 to abort if
certain getters are accessed. It's possible to access these getters and
functions during class construction through the AsyncWrap init()
callback, and also possible in a subset of those scenarios while running
the persistent handle visitor.
Mitigate this issue by manually setting the internal aligned pointer
field to nullptr in the BaseObject constructor and add necessary logic
to return appropriate values when nullptr is encountered.
PR-URL: https://github.com/nodejs/node/pull/6184
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
To prevent `ARRAY_SIZE(&arg)` (i.e., taking the array size of a pointer)
from happening again.
PR-URL: https://github.com/nodejs/node/pull/5969
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Expose and use in TLSWrap an `v8::External` wrap of the
`StreamBase*` pointer instead of guessing the ancestor C++ class in
`node_wrap.h`.
Make use of `StreamBase::Callback` structure for storing/passing both
callback and context in a single object.
Introduce `GetObject()` for future user-land usage, when a child class
is not going to be inherited from AsyncWrap.
PR-URL: https://github.com/nodejs/node/pull/2351
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Dispatch requests in the implementation of the stream, not in the code
creating these requests. The requests might be piled up and invoked
internally in the implementation, so it should know better when it is
the time to dispatch them.
In fact, TLS was doing exactly this thing which led us to...
Fix: https://github.com/iojs/io.js/issues/1512
PR-URL: https://github.com/iojs/io.js/pull/1563
Reviewed-By: Shigeki Ohtsu <ohtsu@iij.ad.jp>
Encapsulate allocation/disposal of `WriteWrap` instances into the
`WriteWrap` class itself.
PR-URL: https://github.com/iojs/io.js/pull/1090
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't include tls_wrap.h in stream_base.cc. It's not used and it breaks
the build when --without-ssl is passed to configure.
Fixes the following build error:
In file included from ../src/tls_wrap.h:5:0,
from ../src/stream_base.cc:10:
../src/node_crypto.h:20:25: fatal error: openssl/ssl.h:
No such file or directory
#include <openssl/ssl.h>
PR-URL: https://github.com/iojs/io.js/pull/1027
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Move JS methods to the stream_base-inl.h and thus define them on each
use of `StreamBase::AddMethods`. Inline `AddMethods` itself, so that
there won't be any need in a static declaration in stream_base.cc.
NOTE: This basically allows using this API in user-land, though, some
polishing is required before releasing it.
PR-URL: https://github.com/iojs/io.js/pull/957
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Introduce a way to wrap plain-js `stream.Duplex` streams into C++
StreamBase's child class. With such method at hand it is now possible to
pass `stream.Duplex` instance as a `socket` parameter to
`tls.connect()`.
PR-URL: https://github.com/iojs/io.js/pull/926
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
StreamBase is an improved way to write C++ streams. The class itself is
for separting `StreamWrap` (with the methods like `.writeAsciiString`,
`.writeBuffer`, `.writev`, etc) from the `HandleWrap` class, making
possible to write abstract C++ streams that are not bound to any uv
socket.
The following methods are important part of the abstraction (which
mimics libuv's stream API):
* Events:
* `OnAlloc(size_t size, uv_buf_t*)`
* `OnRead(ssize_t nread, const uv_buf_t*, uv_handle_type pending)`
* `OnAfterWrite(WriteWrap*)`
* Wrappers:
* `DoShutdown(ShutdownWrap*)`
* `DoTryWrite(uv_buf_t** bufs, size_t* count)`
* `DoWrite(WriteWrap*, uv_buf_t*, size_t count, uv_stream_t* handle)`
* `Error()`
* `ClearError()`
The implementation should provide all of these methods, thus providing
the access to the underlying resource (be it uv handle, TLS socket, or
anything else).
A C++ stream may consume the input of another stream by replacing the
event callbacks and proxying the writes. This kind of API is actually
used now for the TLSWrap implementation, making it possible to wrap TLS
stream into another TLS stream. Thus legacy API calls are no longer
required in `_tls_wrap.js`.
PR-URL: https://github.com/iojs/io.js/pull/840
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
