Adds `AsyncWrap::AddWrapMethods()` to add common methods
to a `Local<FunctionTemplate>`. Follows same pattern as
stream base.
PR-URL: https://github.com/nodejs/node/pull/14937
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This commit replaces a fprintf() with a call to
ProcessEmitWarning().
Refs: https://github.com/nodejs/node/issues/12706
PR-URL: https://github.com/nodejs/node/pull/12709
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Allow handles to retrieve their own uid's by adding a new method on the
FunctionTemplates. Implementation of these into all other classes will
come in a future commit.
Add the method AsyncWrap::GetAsyncId() to all inheriting class objects
so the uid of the handle can be retrieved from JS.
In all applicable locations, run ClearWrap() on the object holding the
pointer so that it never points to invalid memory and make sure Wrap()
is always run so the class pointer is correctly attached to the object
and can be retrieved so GetAsyncId() can be run.
In many places a class instance was not removing its own pointer from
object() in the destructor. This left an invalid pointer in the JS
object that could cause the application to segfault under certain
conditions.
Remove ClearWrap() from ReqWrap for continuity. The ReqWrap constructor
was not the one to call Wrap(), so it shouldn't be the one to call
ClearWrap().
Wrap() has been added to all constructors that inherit from AsyncWrap.
Normally it's the child most class. Except in the case of HandleWrap.
Which must be the constructor that runs Wrap() because the class pointer
is retrieved for certain calls and because other child classes have
multiple inheritance to pointer to the HandleWrap needs to be stored.
ClearWrap() has been placed in all FunctionTemplate constructors so that
no random values are returned when running getAsyncId(). ClearWrap() has
also been placed in all class destructors, except in those that use
MakeWeak() because the destructor will run during GC. Making the
object() inaccessible.
It could be simplified to where AsyncWrap sets the internal pointer,
then if an inheriting class needs one of it's own it could set it again.
But the inverse would need to be true also, where AsyncWrap then also
runs ClearWeak. Unforunately because some of the handles are cleaned up
during GC that's impossible. Also in the case of ReqWrap it runs Reset()
in the destructor, making the object() inaccessible. Meaning,
ClearWrap() must be run by the class that runs Wrap(). There's currently
no generalized way of taking care of this across all instances of
AsyncWrap.
I'd prefer that there be checks in there for these things, but haven't
found a way to place them that wouldn't be just as unreliable.
Add test that checks all resources that can run getAsyncId(). Would like
a way to enforce that any new classes that can also run getAsyncId() are
tested, but don't have one.
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>
Use `static` definitions and anonymous namespaces to reduce the
number of symbols that are exported from the `node` binary.
PR-URL: https://github.com/nodejs/node/pull/12366
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/7990
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yorkie Liu <yorkiefixer@gmail.com>
Use `HAVE_INSPECTOR` as the 0/1 boolean macro that it is, as opposed
to a defined/not-defined boolean.
PR-URL: https://github.com/nodejs/node/pull/7078
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This change introduces experimental v8-inspector support. This brings
the DevTools debug protocol allowing Node.js to be debugged with
Chrome DevTools native, or through other debuggers supporting that
protocol.
Partial WebSocket support, to the extent required by DevTools, is
included. This is derived from the implementation in Blink.
v8-inspector support can be disabled by the --without-inspector
configure flag.
PR-URL: https://github.com/nodejs/node/pull/6792
Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Reviewed-By: addaleax - Anna Henningsen <anna@addaleax.net>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
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>
This fixes my perceived usability issues with 7d8882b. Which, at the
time of writing, has not landed in any release except v6 RCs. This
should not be considered a breaking change due to that.
It is useful if you have a handle, even if it has been closed, to be
able to inspect whether that handle was unrefed or not. As such, this
renames the method accordingly. If people need to check a handle's
aliveness, that is a separate API we should consider exposing.
Refs: https://github.com/nodejs/node/pull/5834
PR-URL: https://github.com/nodejs/node/pull/6204
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
This allows third-party tools to check whether or not a handle that
can be unreferenced is unreferenced at a particular time.
Notably, this should be helpful for inspection via AsyncWrap.
Also, this is useful even to node's internals, particularly timers.
Refs: https://github.com/nodejs/node/pull/5828
Refs: https://github.com/nodejs/node/pull/5827
PR-URL: https://github.com/nodejs/node/pull/5834
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Re-add the wrapper class id to AsyncWrap instances so they can be
tracked directly in a heapdump.
Previously the class id was given without setting the heap dump wrapper
class info provider. Causing a segfault when a heapdump was taken. This
has been added, and the label_ set to the given provider name so each
instance can be identified.
The id will not be set of the passed object has no internal field count.
As the class pointer cannot be retrieved from the object.
In order to properly report the allocated size of each class, the new
pure virtual method self_size() has been introduces.
PR-URL: https://github.com/nodejs/io.js/pull/1896
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Attach the per-context execution environment directly to API functions.
Rationale:
* Gets node one step closer to multi-isolate readiness.
* Avoids multi-context confusion, e.g. when the caller and callee live
in different contexts.
* Avoids expensive calls to pthread_getspecific() on platforms where
V8 does not know how to use the thread-local storage directly.
(Linux, the BSDs.)
PR-URL: https://github.com/node-forward/node/pull/18
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Mechanically replace assert() statements with UNREACHABLE(), CHECK(),
or CHECK_{EQ,NE,LT,GT,LE,GE}() statements.
The exceptions are src/node.h and src/node_object_wrap.h because they
are public headers.
PR-URL: https://github.com/node-forward/node/pull/16
Reviewed-By: Fedor Indutny <fedor@indutny.com>
API callback functions don't need to create a v8::HandleScope instance
because V8 already creates one in the JS->C++ adapter frame.
PR-URL: https://github.com/node-forward/node/pull/16
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Replace the CONTAINER_OF macro with a template function that is as
type-safe as a reinterpret_cast<> of an arbitrary pointer can be made.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
This prevents segfaults when a native method is reassigned to a
different object (which corrupts args.This()). When unwrapping,
clients should use args.Holder() instead of args.This().
Closes#6690.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
These will be used to allow users to filter for which types of calls
they wish their callbacks to run.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Built-in modules should be automatically registered, replacing the
static module list. Add-on modules should also be automatically
registered via DSO constructors. This improves flexibility in adding
built-in modules and is also a prerequisite to pure-C addon modules.
Create a HandleScope before calling the Environment::GetCurrent() that
takes a v8::Isolate* as an argument because it creates a handle with
the call to v8::Isolate::CurrentContext().
CONTAINER_OF was introduced a while ago but was not used consistently
everywhere yet. This commit fixes that.
Why CONTAINER_OF instead of container_of? The former makes it crystal
clear that it's a macro, not a function.
AsyncListener is a JS API that works in tandem with the AsyncWrap class
to allow the user to be alerted to key events in the life cycle of an
asynchronous event. The AsyncWrap class has its own MakeCallback
implementation that core will be migrated to use, and uses state sharing
techniques to allow quicker communication between JS and C++ whether the
async event callbacks need to be called.
This commit makes it possible to use multiple V8 execution contexts
within a single event loop. Put another way, handle and request wrap
objects now "remember" the context they belong to and switch back to
that context when the time comes to call into JS land.
This could have been done in a quick and hacky way by calling
v8::Object::GetCreationContext() on the wrap object right before
making a callback but that leaves a fairly wide margin for bugs.
Instead, we make the context explicit through a new Environment class
that encapsulates everything (or almost everything) that belongs to
the context. Variables that used to be a static or a global are now
members of the aforementioned class. An additional benefit is that
this approach should make it relatively straightforward to add full
isolate support in due course.
There is no JavaScript API yet but that will be added in the near
future.
This work was graciously sponsored by GitHub, Inc.
* Change calls to String::New() and String::NewSymbol() to their
respective one-byte, two-byte and UTF-8 counterparts.
* Add a FIXED_ONE_BYTE_STRING macro that takes a string literal and
turns it into a v8::Local<v8::String>.
* Add helper functions that make v8::String::NewFromOneByte() easier to
work with. Said function expects a `const uint8_t*` but almost every
call site deals with `const char*` or `const unsigned char*`. Helps
us avoid doing reinterpret_casts all over the place.
* Code that handles file system paths keeps using UTF-8 for backwards
compatibility reasons. At least now the use of UTF-8 is explicit.
* Remove v8::String::NewSymbol() entirely. Almost all call sites were
effectively minor de-optimizations. If you create a string only once,
there is no point in making it a symbol. If you are create the same
string repeatedly, it should probably be cached in a persistent
handle.
Libuv now returns errors directly. Make everything in src/ and lib/
follow suit.
The changes to lib/ are not strictly necessary but they remove the need
for the abominations that are process._errno and node::SetErrno().
This is a big commit that touches just about every file in the src/
directory. The V8 API has changed in significant ways. The most
important changes are:
* Binding functions take a const v8::FunctionCallbackInfo<T>& argument
rather than a const v8::Arguments& argument.
* Binding functions return void rather than v8::Handle<v8::Value>. The
return value is returned with the args.GetReturnValue().Set() family
of functions.
* v8::Persistent<T> no longer derives from v8::Handle<T> and no longer
allows you to directly dereference the object that the persistent
handle points to. This means that the common pattern of caching
oft-used JS values in a persistent handle no longer quite works,
you first need to reconstruct a v8::Local<T> from the persistent
handle with the Local<T>::New(isolate, persistent) factory method.
A handful of (internal) convenience classes and functions have been
added to make dealing with the new API a little easier.
The most visible one is node::Cached<T>, which wraps a v8::Persistent<T>
with some template sugar. It can hold arbitrary types but so far it's
exclusively used for v8::Strings (which was by far the most commonly
cached handle type.)