bigeasy / olio / 91

100%

push

travis-ci

`unref` server, `kill` instead of `disconnect`.

Was hanging because sockets where not closing when they where in transit
between processes in the pipe. At first it seemed like the problem was
simply that `destroy` was not being called. I'd added `socket-destroy`
but that didn't help because the sockets had been handed off. I thought
I'd fix it by setting a destructor on the sockets as they arrived in the
child, but the next problem was that after the first error crashed the
first child, the subsequent sockets failed to reach the children. There
was no way to set a destructor. The server was going to wait for these
missing sockets to close before it closed so the Destructible module
decided that the server process was hung and brought it crashing down.

Tried to set a message listener on the `process` in the child to see if
the message arrived. Didn't see it arrive. Also, crashed the parent from
within Node.js itself, with an assertion failure from the C++.

It appears that passing socket handles is not guaranteed. You're not
able to ensure that a handle in the pipe gets an explicit close. You
could only call `close` when the socket object arrives in the child.

Went and had the `bin/echo.bin.js` thrown an exception on second after
startup. Saw that all the child processes exited completely, but close
event on the server was never emitted. Servers do seem to lose track of
their socket handles once they get passed to children, so it doesn't
seem to matter whether the child closes them or not.

This is why I'm now using `unref` on the socket server. No more waiting
for it to close.

The search for a way to close sockets in the child was not exhaustive,
however. There could still be a way to keep the channel open long enough
to close sockets passed by pipe, but I'm not willing to invest the time
right now to find it. I'm okay with this particular instance of lax
accounting given that the issue effects only the core UNIX domain
server. It is a special cas... (continued)

33 of 33 branches covered (100.0%)

Branch coverage included in aggregate %.

414 of 416 relevant lines covered (99.52%)

7.02 hits per line