This is because it would call the javascript initializer which executed
Promise::New, and then it would rewrap the handle. Instead I make an
explicit inheritance from EIOPromise to Promise.
This seems to fix a memory leak which was reported by Ray Morgan:
http://groups.google.com/group/nodejs/browse_thread/thread/e38949b1989da1d7
Instead of
myemitter.emit("event", [arg1, arg2, arg3]);
the API is now
myemitter.emit("event", arg1, arg2, arg3);
This change saves the creation of an extra array object for each event.
The implementation is also slightly more simple.
The problem was that if promise A was waiting and promise B was created and
then also told to wait (from some callback coming off the event loop), and
then promise A finished, promise B's wait would return. Promise A's wait
would not return until promise B was finished. This is incorrect.
To solve this issue properly, one probably needs to allocate separate
execution stacks. I use, instead, Poor Man's Coroutines. We continue to use
the main execution stack and force promises created most recently to return
first.
That is even if Promise A finishes first, neither wait() returns. Not until
Promise B finishes, will its wait() return. After that is complete, Promise
A's wait() will return.
This introduces the problem of growing the "wait stack" infinitely. Thus
I've added a strong warning to the documentation only to use this operation
sparingly. require() and include() seem to be the proper use case for such a
thing: they are called usually at program start up - they don't take too
long to finish and they won't be called so often.
Let's experiment with this stop-gap. If the infinite promise stack becomes a
problem for many, then I will remove promise.wait() entirely or perhaps only
use it for thread pool events.
This change also tries to optimize Emit by looping through the listeners in
C++. The javascript version of this function is still there and being used,
but only by javascript code. Not an ideal solution - there should only be
one implementation - however for now it seems to help.
This doesn't solve all of the memory leaks that we're experiencing, there
seems to be another subtle problem.
Simplify and inline ObjectWrap::Wrap
Inline and clean up ObjectWrap::Unwrap
Move ObjectWrap into its own file.
Remove handle from ObjectWrap constructor. add obj->Wrap(handle)
Simplify Attach/Detach in ObjectWrap
Remove ObjectWrap::InformV8ofAllocation. (Too messy/complex.)
The constructor for TCP servers can no longer take a connection handler for
purely technical reasons. (The constructor for EventEmitter is implemented
in C++ but addListener is in javascript, and I don't want to make too many
C++ -> Javascript references.) Thus I introduce new constructor methods to
ease the creation of the servers:
node.tcp.createServer()
node.http.createServer()
These work almost the same as the old constructors.
In general we're working towards a future where no constructors are
publicly exposed or take arguments.
The HTTP events like "on_uri" are not yet using the event interface.
onMessage still is a constructor - but this will change soon.
Ryan Dahl