One of the issues in #4641 concerns OnConnection in pipe_wrap and
tcp_wrap which are very similar with some minor difference in how
they are coded. This commit extracts OnConnection so both these
classes can share the same implementation.
PR-URL: https://github.com/nodejs/node/pull/7547
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
For consistency with the newly added src/base64.h header, check that
NODE_WANT_INTERNALS is defined and set in internal headers.
PR-URL: https://github.com/nodejs/node/pull/6948
Refs: https://github.com/nodejs/node/pull/6910
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
The BaseObject constructor and destructor should not have external
linkage because BaseObject is a header-only construct. Add the
necessary 'inline' keywords.
PR-URL: https://github.com/nodejs/node/pull/6056
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This reverts commit 3c44100558.
Reverted for breaking node-heapdump[0].
AsyncWrap assigns a class id but does not set a v8::RetainedObjectInfo
provider callback with v8::HeapProfiler::SetWrapperClassInfoProvider().
The result is a null pointer dereference when taking a heap snapshot.
It can probably be solved by setting a generic provider callback inside
the AsyncWrap constructor but that may have performance ramifications
that need to be investigated first. I move to revert it for now.
[0] https://github.com/bnoordhuis/node-heapdump
PR-URL: https://github.com/nodejs/io.js/pull/1827
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Pass along the PROVIDER type, that is already passed to AsyncWrap, along
to BaseObject to set the handle_'s class id. This will allow all
Persistents to be transversed and uniquely identified by what type they
are using APIs such as v8::PersistentHandleVisitor.
PR-URL: https://github.com/nodejs/io.js/pull/1730
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This commit also breaks up req_wrap.h into req-wrap.h and req-wrap-inl.h
to work around a circular dependency issue in env.h.
PR-URL: https://github.com/iojs/io.js/pull/667
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
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.
It's safe to call BaseObject::object() from your destructor _unless_
the handle is weak; then it's the weak callback that is calling your
destructor and the object will have been released by the time the
destructor runs.
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
BaseObject is a class that just handles the Persistent handle attached
to the class instance.
This also removed WeakObject. Reordering the inheritance chain helps
prevent unneeded calls on instances that don't call MakeCallback.
Drop the ObjectWrap dependency in favor of an internal WeakObject class.
Let's us stop worrying about API and ABI compatibility when making
changes to the way node.js deals with weakly persistent handles
internally.
Fix pointer unwrapping when T is a class with more than one base class.
Before this commit, the wrapped void* pointer was cast directly to T*
without going through ObjectWrap* first, possibly leading to a class
instance pointer that points to the wrong vtable.
This change required some cleanup in various files; some classes
used private rather than public inheritance, others didn't derive
from ObjectWrap at all...
Fixes#6188.
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.
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.)
While libuv supports reporting subsecond stat resolution across
platforms, to actually get that resolution your platform and filesystem
must support it (not HFS, ext[23], fat), otherwise the nsecs are 0