In Snow Leopard "platform.machine()" returns "i386" while
"platform.architecture()" returns ('64bit',''). Using information from both
we can determine the proper architecture
This reverts commit ea29e137b5 re-enabling the
64bit build on Macintosh.
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.
I don't have access to this OS to fix the issue properly, so for the moment
I'm reverting back to 32bit build on Darwin. We changed to native 64bit in
8ddf930901.
Thanks to Johan Dahlberg and Tim Caswell for reporting and debugging this.
I'm not sure what is actually causing
node_g test/mjsunit/test-tcp-many-clients.js
to run slowly, but I traced the problem to
afd9e714d3.
Somehow it has to do with promoting the compilation of src/util.js. That
change wasn't actually intended to be included in afd9e7 commit anyway, so
I'm reverting it here.
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.
Had to add some waf hackery to override V8's architecture choice. They
probably have a reason for defaulting still to IA32, but all tests are
passing for me, and it makes it easier on users-and I think chrome is using
x64 builds too. So let's go for it!
