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.
promise.wait() now returns the arguments of the "success" event. If there
was only a single argument, then it is returned. If there was more than
one, they are returned as an array. If there was an error, it is thrown.
See documentation.
With the addition of non-libeio stdio (17c6a67f15)
this class is no longer being used internally. It has proved buggy and isn't
full-featured enough to be very useful. Since it's implemented entirely in
javascript it will be easy for someone to extra into their own library if
needed.
Solution is to manually add Attach() to OnConnection.
For client side it seems there is no Detach() being called after NS
resolution? Otherwise I would have removed it. That was another bug.
Note: We don't want to modify evnet's behavior to have on_connect called
directly when the socket is accepted. evnet needs to support SSL, and
on_connect is supposed to signal that the SSL connection is established. The
point here is that being "connected" and being "attached" to the event loop
are two different things. SSL stuff may be transmitted when a socket is not
"connected" but it must always be attached.
The problem was that Connection::on_close was calling Detach() directly
after executing the "disconnect" event. Since we had a boolean attach count,
this was leaving sockets detached even if they had reattached in during the
event.
* Added many asserts in http.cc and net.cc to ensure that sockets are
connected when they should be.
* Changed ObjectWrap to use a reference count instead of boolean attached_
value.
* Fixed similar bug in Timer.
This is a rather large refactor! Mostly for the better side. I've had to
remove some functionality like req.interrupt(). A lot of other work is left
messy or incomplete.
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.
This requires that onExit() is not called immediately upon receiving a
SIGCHLD. There could still be data in the pipez. So, instead just set a
flag and invoke the pipe watchers.
Sometimes one will not receive an EOF from pipes because the process was
killed by a SIGTERM, or something. If SIGCHLD has been recved but we are
getting EAGAIN, the pipez need to be closed too.
Ryan
Joshaven Potter
Urban Hafner