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 afd9e71. 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.
64kb seems to be the magic number for getaddrinfo() to work on Macintosh.
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.
The error reporting function tries to look at the "stack" element of the exception.
The default timeout is 60 seconds, but it can now be changed. evcom upgrade includes fixes to force_close.
node --cflags node --libs At the expense of some WAF nastiness.