Remove all AsyncListener JS code

[trevnorris]

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

[indutny]

So this is technically leaving us a way to hook this up, right?

[trevnorris]

Yes. This check is for specific cases like incoming TCP connections. Because receiving the connection is asynchronous, the call stack to the server is destroyed. Hence the call to env->set_async_wrap_parent_class<T>() in tcp_wrap just before the instantiation of the JS object for the incoming connection. That way the connection can be traced back to the server that is the reason the incoming connection exists.

Now, to put all that into code comments...

[indutny]

I don't know all details, but it LGTM

[aredridel]

Any tests for the new functionality?

[trevnorris]

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.

[orangemocha]

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

[trevnorris]

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]

@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]

@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]

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

[bnoordhuis]

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

[bnoordhuis]

@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]

@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]

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]

@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]

@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.