Add getter for socket closed state - #181
Conversation
lgeiger
left a comment
There was a problem hiding this comment.
Thanks for adding this. 👍
I agree it's a good idea to have an easy way to see if a socket is closed or not.
|
We need to really improve the docs. I love little additions like this, but there's no way for users to discover them. For the record, and for inspiration, I do have a WIP PR (that has been unfinished for ages, I need to get back to it at some point) with a much more completed ReadMe. By all means have a look and let me know what you think |
|
We should definitely include these changes in the release notes.
I think we should take small parts out of your PR and bring them in as individual PRs. Making the module export no longer the binding is a simple one that we could bring in before we make a major release ( |
|
Oh sure, I was really just aiming at the ReadMe for now :) Would love to get feedback on its form. |
|
The getter works when |
In my code I have found it useful to be able to determine if a socket is closed. This is information is already kept in a
statevariable in the C++ bindings, but not exposed as public API.This PR proposes to add a
socket.closedgetter, which returns a boolean.(An alternative implementation would be a
socket.stategetter which returns the socket's internal state. Which state values are possible would not be immediately obvious to me, so I'm proposing this boolean getter instead.)The background of being able to check if a socket is closed is that some monitor events (and other events in my application) can occur slightly out of order due to timing issues native to how Node works. As such it is nice to avoid calling
socket.send()or something similar if the socket was already closed withsocket.close()as a result of another event. Of course I could keep this state in my application, but that seems needlessly complex given that the bindings already keep track of the state of the socket!