Skip to content

Conversation

justfalter
Copy link

If client.destroy() is called, always destroy the underlying socket so
that file descriptor is freed. This matches behavior of node's Socket and
Writable.

Previous behavior made this conditional on writability of the socket.
If the socket wasn't writable, then client.destroy() wouldn't actually
destroy the socket, the file descriptor would remain open, and the
node process would hang on exit.. It might timeout after 15 minutes, if
you're lucky.

fixes #1124

If client.destroy() is called, always destroy the underlying socket so
that file descriptor is freed. This matches behavior of node's Socket and
Writable.

Previous behavior made this conditional on writability of the socket.
If the socket wasn't writable, then client.destroy() wouldn't actually
destroy the socket, the file descriptor would remain open, and the
node process would hang on exit.. It might timeout after 15 minutes, if
you're lucky.

fixes mscdex#1124
@justfalter
Copy link
Author

Note: Prior to this large refactor, client.destroy() wouldn't check to see if the socket was writable, it'd just destroy it. I ran into this issue after upgrading to 1.5.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Client.destroy() does not always destroy the socket, node hangs on exit

2 participants