This repository has been archived by the owner. It is now read-only.

Remove all AsyncListener JS code #8110

Closed
wants to merge 9 commits into
base: v0.12
from

Conversation

Projects
None yet
9 participants
@trevnorris

trevnorris commented Aug 8, 2014

Squashed for simplicity. There are also changes in the naming of some of the native API's so what it's called actually reflects what is going on. Also added a few TODO's, etc.

Review, comment, and if necessary I'll break up the commits into relevant segments.

Also, didn't add tjfontaine@6a74d6c to the changes. If that conditional is hit then there's a bug in the code. I'd rather add an ASSERT() or the like that can be reported instead of silently ignored.

/cc @tjfontaine @indutny @orangemocha

@tjfontaine tjfontaine added in progress and removed pr labels Aug 8, 2014

@trevnorris trevnorris self-assigned this Aug 8, 2014

@trevnorris trevnorris added this to the v0.12 milestone Aug 8, 2014

@indutny

View changes

Show outdated Hide outdated src/async-wrap-inl.h
@indutny

View changes

Show outdated Hide outdated src/util.h
@indutny

View changes

Show outdated Hide outdated src/util.h
@indutny

This comment has been minimized.

Show comment
Hide comment
@indutny

indutny Aug 8, 2014

Member

I don't know all details, but it LGTM

Member

indutny commented Aug 8, 2014

I don't know all details, but it LGTM

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Aug 9, 2014

Any tests for the new functionality?

aredridel commented Aug 9, 2014

Any tests for the new functionality?

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 9, 2014

The hooks will remain accessible via process.binding('async_listener'), and
the added functionality will live in an external module.

@tjfontaine, basic tests could be added to make sure functionality to the
binding is working correctly. Don't think that should prevent this PR
(which is holding up the v0.12 release) from landing, but I'll work on
those.

trevnorris commented Aug 9, 2014

The hooks will remain accessible via process.binding('async_listener'), and
the added functionality will live in an external module.

@tjfontaine, basic tests could be added to make sure functionality to the
binding is working correctly. Don't think that should prevent this PR
(which is holding up the v0.12 release) from landing, but I'll work on
those.

@loyd loyd referenced this pull request Aug 11, 2014

Closed

Fix timers #8120

@orangemocha

This comment has been minimized.

Show comment
Hide comment
@orangemocha

orangemocha Aug 11, 2014

Member

Passed Windows build and tests so I give you my +1

Member

orangemocha commented Aug 11, 2014

Passed Windows build and tests so I give you my +1

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 11, 2014

For the sake of #8090, I've added an additional commit that gives all AsyncWrap instances a unique id. The change is minimal at best, but takes a different approach than that in the other PR.

/cc @bnoordhuis

trevnorris commented Aug 11, 2014

For the sake of #8090, I've added an additional commit that gives all AsyncWrap instances a unique id. The change is minimal at best, but takes a different approach than that in the other PR.

/cc @bnoordhuis

@kraman

This comment has been minimized.

Show comment
Hide comment
@kraman

kraman Aug 12, 2014

@trevnorris I find @bnoordhuis's af669a5 commit to also be very useful in tracking the lifecycle of a handles. I am using it in Zones to do the same. Since this is an addition to the AsyncWrap, can you please take a look and see if it makes sense to add a similar commit to this PR?

kraman commented Aug 12, 2014

@trevnorris I find @bnoordhuis's af669a5 commit to also be very useful in tracking the lifecycle of a handles. I am using it in Zones to do the same. Since this is an addition to the AsyncWrap, can you please take a look and see if it makes sense to add a similar commit to this PR?

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 12, 2014

@kraman The specific change I included is how the id of the AsyncWrap instance is accessed. It wasn't meant to replace the additional functionality included in @bnoordhuis' PR. That is distinct from AsyncWrap directly, and should be in another PR.

trevnorris commented Aug 12, 2014

@kraman The specific change I included is how the id of the AsyncWrap instance is accessed. It wasn't meant to replace the additional functionality included in @bnoordhuis' PR. That is distinct from AsyncWrap directly, and should be in another PR.

@kraman

This comment has been minimized.

Show comment
Hide comment
@kraman

kraman Aug 12, 2014

@trevnorris ok, thanks. I'll look into rebasing @bnoordhuis's PR unless he gets to it first

kraman commented Aug 12, 2014

@trevnorris ok, thanks. I'll look into rebasing @bnoordhuis's PR unless he gets to it first

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Aug 12, 2014

Member

@kraman I would suggest holding off until this PR lands.

Member

bnoordhuis commented Aug 12, 2014

@kraman I would suggest holding off until this PR lands.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Aug 22, 2014

Member

@trevnorris I think there is at least one place where AsyncWrap::AddMethods() isn't getting applied (to fs request objects in node_file.cc) and there may be more.

Maybe it's better to make everything inherit from a common ObjectTemplate. That would also make it easier to protect against invocations with the wrong holder (req.asyncId.call({}).)

Member

bnoordhuis commented Aug 22, 2014

@trevnorris I think there is at least one place where AsyncWrap::AddMethods() isn't getting applied (to fs request objects in node_file.cc) and there may be more.

Maybe it's better to make everything inherit from a common ObjectTemplate. That would also make it easier to protect against invocations with the wrong holder (req.asyncId.call({}).)

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 22, 2014

@bnoordhuis

I think there is at least one place where AsyncWrap::AddMethods() isn't getting applied

Correct. Now that you bring it up, I remember now that the first method was only added to the classes where it was necessary to be called from JS. Forgot about that.

Maybe it's better to make everything inherit from a common ObjectTemplate.

I like the idea, but have an idea how to implement this? Can't think of how to create a "base" ObjectTemplate and have other inheriting classes inherit from that.

trevnorris commented Aug 22, 2014

@bnoordhuis

I think there is at least one place where AsyncWrap::AddMethods() isn't getting applied

Correct. Now that you bring it up, I remember now that the first method was only added to the classes where it was necessary to be called from JS. Forgot about that.

Maybe it's better to make everything inherit from a common ObjectTemplate.

I like the idea, but have an idea how to implement this? Can't think of how to create a "base" ObjectTemplate and have other inheriting classes inherit from that.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Aug 22, 2014

Member

I like the idea, but have an idea how to implement this? Can't think of how to create a "base" ObjectTemplate and have other inheriting classes inherit from that.

It probably requires a fair amount of rework so I was hoping you'd volunteer. :-)

What I think needs to happen is that you have a single FunctionTemplate with a configured InstanceTemplate (that's the ObjectTemplate) for constructing plain request and handle objects. Utility methods like .asyncId() can then go on the PrototypeTemplate.

If you need to specialize for a request or handle type, you create a new FunctionTemplate and make it inherit from the main one with FunctionTemplate::Inherit(). Prototypal inheritance in JS would also work but Inherit() might be more efficient.

Member

bnoordhuis commented Aug 22, 2014

I like the idea, but have an idea how to implement this? Can't think of how to create a "base" ObjectTemplate and have other inheriting classes inherit from that.

It probably requires a fair amount of rework so I was hoping you'd volunteer. :-)

What I think needs to happen is that you have a single FunctionTemplate with a configured InstanceTemplate (that's the ObjectTemplate) for constructing plain request and handle objects. Utility methods like .asyncId() can then go on the PrototypeTemplate.

If you need to specialize for a request or handle type, you create a new FunctionTemplate and make it inherit from the main one with FunctionTemplate::Inherit(). Prototypal inheritance in JS would also work but Inherit() might be more efficient.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2014

@bnoordhuis Pretty much anything that inherits from ReqWrap doesn't receive the added methods. This is because it expects an object to be passed in when instantiated. Take for example how it's done in lib/dgram.js:

      var req = { buffer: buffer, length: length };  // Keep reference alive.
      if (callback) {
        req.callback = callback;
        req.oncomplete = afterSend;
      }
      var err = self._handle.send(req,
                                  buffer,
                                  // ...

I'm sure you see what's going on.

Right now I'm trying to think of a quicker way to fix this so it can be merged and v0.12 can be closer to being shipped. Then finish the more "elegant" way later. It'll come at a performance hit. Not sure how much. Going to give it a go and see how much of a difference it'll make.

trevnorris commented Aug 26, 2014

@bnoordhuis Pretty much anything that inherits from ReqWrap doesn't receive the added methods. This is because it expects an object to be passed in when instantiated. Take for example how it's done in lib/dgram.js:

      var req = { buffer: buffer, length: length };  // Keep reference alive.
      if (callback) {
        req.callback = callback;
        req.oncomplete = afterSend;
      }
      var err = self._handle.send(req,
                                  buffer,
                                  // ...

I'm sure you see what's going on.

Right now I'm trying to think of a quicker way to fix this so it can be merged and v0.12 can be closer to being shipped. Then finish the more "elegant" way later. It'll come at a performance hit. Not sure how much. Going to give it a go and see how much of a difference it'll make.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2014

@bnoordhuis I'm curious if the API itself isn't an issue to make asyncId() useful. For example:

var dgram = require('dgram');
var b = new Buffer('hi\n');
var s = dgram.createSocket('udp4');
s.bind(8000);

// This returns nothing.
s.send(b, 0, b.length, 8000, 'localhost', function cb() {
  // Access to asyncId() is only available here.
  console.log(this.asyncId());
});

You'll see by my latest commits how I'm planning on addressing the issue in the interim, but the fact that the request id isn't accessible until after the request is made sort of defeats the need.

As for performance, specifically the dgram case, there is no performance hit. In fact, it's a hair faster. Statistically pretty much within the margin of error, but still is consistently faster.

trevnorris commented Aug 26, 2014

@bnoordhuis I'm curious if the API itself isn't an issue to make asyncId() useful. For example:

var dgram = require('dgram');
var b = new Buffer('hi\n');
var s = dgram.createSocket('udp4');
s.bind(8000);

// This returns nothing.
s.send(b, 0, b.length, 8000, 'localhost', function cb() {
  // Access to asyncId() is only available here.
  console.log(this.asyncId());
});

You'll see by my latest commits how I'm planning on addressing the issue in the interim, but the fact that the request id isn't accessible until after the request is made sort of defeats the need.

As for performance, specifically the dgram case, there is no performance hit. In fact, it's a hair faster. Statistically pretty much within the margin of error, but still is consistently faster.

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

src: remove Async Listener
Async Listener was the name of the user-facing JS API, and is being
completely removed. Instead low level hooks directly into the mechanism
that AL used will be introduced in a future commit.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

async-wrap: move MakeCallback to .cc
MakeCallback is too large a function to be inlined. Likewise, only
having header files will not allow for any part of AsyncWrap to be
exposed cleanly via NODE_MODULE_CONTEXT_AWARE_BUILTIN().

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

node, async-wrap: remove MakeDomainCallback
C++ won't deoptimize like JS if specific conditional branches are
sporadically met in the future. Combined with the amount of code
duplication removal and simplified maintenance complexity, it makes more
sense to merge MakeCallback and MakeDomainCallback.

Additionally, type casting in V8 before verifying what that type is will
cause V8 to abort in debug mode if that type isn't what was expected.
Fix this by first checking the v8::Value before casting.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

node: fix throws before timer module is loaded
An edge case could occur when the setImmediate() in _fatalException()
would fire before the timers module had been loaded globally, causing
Node to crash.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

src: all wraps now use actual FunctionTemplate
Instead of simply creating a new v8::Object to contain the connection
information, instantiate a new instance of a FunctionTemplate. This will
allow future improvements for debugging and performance probes.

Additionally, the "provider" argument in the ReqWrap constructor is no
longer optional.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

src: remove unnecessary template parameter
The template class information is received via the type of the first
argument. So there is no need to use Wrap<T>(handle).

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

async-wrap: expose async-wrap as binding
Expose basic hooks for AsyncWrap via the async_wrap binding. Right now
only the PROVIDER types are exposed. This is a preliminary step before
more functionality is added.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

async-wrap: explicitly pass parent
When instantiating a new AsyncWrap allow the parent AsyncWrap to be
passed. This is useful for cases like TCP incoming connections, so the
connection can be tied to the server receiving the connection.

Because the current architecture instantiates the *Wrap inside a
v8::FunctionCallback, the parent pointer is currently wrapped inside a
new v8::External every time and passed as an argument. This adds ~80ns
to instantiation time.

A future optimization would be to add the v8::External as the data field
when creating the v8::FunctionTemplate, change the pointer just before
making the call then NULL'ing it out afterwards. This adds enough code
complexity that it will not be attempted until the current approach
demonstrates it is a bottle neck.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

piscisaureus added a commit to piscisaureus/node2 that referenced this pull request Dec 9, 2014

async-wrap: add event hooks
Call a user-defined callback at specific points in the lifetime of an
asynchronous event. Which are on instantiation, just before/after the
callback has been run.

**If any of these callbacks throws an exception, there is no forgiveness
or recovery. A message will be displayed and a core file dumped.**

Currently these only tie into AsyncWrap, meaning no call to a hook
callback will be made for timers or process.nextTick() events. Though
those will be added in a future commit.

Here are a few notes on how to make the hooks work:

- The "this" of all event hook callbacks is the request object.

- The zero field (kCallInitHook) of the flags object passed to
  setupHooks() must be set != 0 before the init callback will be called.

- kCallInitHook only affects the calling of the init callback. If the
  request object has been run through the create callback it will always
  run the before/after callbacks. Regardless of kCallInitHook.

- In the init callback the property "_asyncQueue" must be attached to
  the request object. e.g.

  function initHook() {
    this._asyncQueue = {};
  }

- DO NOT inspect the properties of the object in the init callback.
  Since the object is in the middle of being instantiated there are some
  cases when a getter is not complete, and doing so will cause Node to
  crash.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

src: remove Async Listener
Async Listener was the name of the user-facing JS API, and is being
completely removed. Instead low level hooks directly into the mechanism
that AL used will be introduced in a future commit.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

async-wrap: move MakeCallback to .cc
MakeCallback is too large a function to be inlined. Likewise, only
having header files will not allow for any part of AsyncWrap to be
exposed cleanly via NODE_MODULE_CONTEXT_AWARE_BUILTIN().

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

node, async-wrap: remove MakeDomainCallback
C++ won't deoptimize like JS if specific conditional branches are
sporadically met in the future. Combined with the amount of code
duplication removal and simplified maintenance complexity, it makes more
sense to merge MakeCallback and MakeDomainCallback.

Additionally, type casting in V8 before verifying what that type is will
cause V8 to abort in debug mode if that type isn't what was expected.
Fix this by first checking the v8::Value before casting.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

node: fix throws before timer module is loaded
An edge case could occur when the setImmediate() in _fatalException()
would fire before the timers module had been loaded globally, causing
Node to crash.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

src: all wraps now use actual FunctionTemplate
Instead of simply creating a new v8::Object to contain the connection
information, instantiate a new instance of a FunctionTemplate. This will
allow future improvements for debugging and performance probes.

Additionally, the "provider" argument in the ReqWrap constructor is no
longer optional.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

src: remove unnecessary template parameter
The template class information is received via the type of the first
argument. So there is no need to use Wrap<T>(handle).

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

async-wrap: expose async-wrap as binding
Expose basic hooks for AsyncWrap via the async_wrap binding. Right now
only the PROVIDER types are exposed. This is a preliminary step before
more functionality is added.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

async-wrap: explicitly pass parent
When instantiating a new AsyncWrap allow the parent AsyncWrap to be
passed. This is useful for cases like TCP incoming connections, so the
connection can be tied to the server receiving the connection.

Because the current architecture instantiates the *Wrap inside a
v8::FunctionCallback, the parent pointer is currently wrapped inside a
new v8::External every time and passed as an argument. This adds ~80ns
to instantiation time.

A future optimization would be to add the v8::External as the data field
when creating the v8::FunctionTemplate, change the pointer just before
making the call then NULL'ing it out afterwards. This adds enough code
complexity that it will not be attempted until the current approach
demonstrates it is a bottle neck.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

trevnorris added a commit to nodejs/node that referenced this pull request Dec 9, 2014

async-wrap: add event hooks
Call a user-defined callback at specific points in the lifetime of an
asynchronous event. Which are on instantiation, just before/after the
callback has been run.

**If any of these callbacks throws an exception, there is no forgiveness
or recovery. A message will be displayed and a core file dumped.**

Currently these only tie into AsyncWrap, meaning no call to a hook
callback will be made for timers or process.nextTick() events. Though
those will be added in a future commit.

Here are a few notes on how to make the hooks work:

- The "this" of all event hook callbacks is the request object.

- The zero field (kCallInitHook) of the flags object passed to
  setupHooks() must be set != 0 before the init callback will be called.

- kCallInitHook only affects the calling of the init callback. If the
  request object has been run through the create callback it will always
  run the before/after callbacks. Regardless of kCallInitHook.

- In the init callback the property "_asyncQueue" must be attached to
  the request object. e.g.

  function initHook() {
    this._asyncQueue = {};
  }

- DO NOT inspect the properties of the object in the init callback.
  Since the object is in the middle of being instantiated there are some
  cases when a getter is not complete, and doing so will cause Node to
  crash.

PR-URL: nodejs/node-v0.x-archive#8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>

@KenanY KenanY referenced this pull request Jan 23, 2015

Closed

tracing module #570

@trevnorris trevnorris referenced this pull request Dec 3, 2015

Closed

AsyncWrap for LTS Argon #59

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.