Users too often would forget to add
socket.on('end', function () {
socket.end();
});
Which is a mistake. Therefore we default to this behavior and
only optionally let people handle the 'end' case themselves.
When a server hit EMFILE it would continue to try to accept new connections
from the queue. This patch introduces a timeout of one second where it will
stop trying to accept new files. After the second is over it tries again.
This is a rather serious bug that has been effecting many highly concurrent
programs. It was introduced in 4593c0, version v0.2.0.
TODO: A test for this situation. Currently I test it like this
termA% cd projects/node
termA% ulimit -n 256
termA% ./node benchmark/idle_server.js
termB% cd projects/node
termB% ./node benchmark/idle_clients.js
And watch how the server process behaves.
- Without this, recvMsg can be invoked before the event emitter gets a
chance to run. In this case, recvMsg.fd will be overwritten and the
original caller can end up emitting null.
This is needed in case the provided socket is not the default 'tcp4' type
(i.e. and needs different read/write/etc methods). With this patch, one can
call listenFD(sock, 'unix') to bind to existing UNIX domain sockets.
Now that FD passing is in master, it'd be great to be able to use a received
socket (which has already had bind(2) and listen(2) called on it) to fire up a
new net.Server instance. This patch adds a net.Server.listenFD() method which
will start up the accept watcher on the provided FD.
a) create a layer of indirection in net.Stream to allow swapping in
different read/write implementations and
b) emit an 'fd' event when file descriptors are received over a UNIX pipe,
as finally as a tangential benefit
c) remove a bunch of conditionals from the primary codepaths for
ease-of-reading.
There is a difference between errors which happen to a socket - like
receiving EPIPE - an exceptional situation but ultimately okay and the
situation where code throws in a callback - which is not okay.
Fixes test/simple/test-http-exceptions.js
TODO: explain this in docs.
- setTimeout should active the timeout too. (test-net-set-timeout tests
this.)
- 'timeout' event is not automatically followed by an 'error' event. That
is the user is now responsible for destroying the stream if there is an
idle timeout.