Support unref method with option to autoUnref
#653
Labels
enhancement
New feature or request
Comments
darrachequesne
added a commit
that referenced
this issue
Mar 3, 2021
With autoUnref set to true (default: false), the Engine.IO client will allow the program to exit if there is no other active timer/socket in the event system. Note: the 'xmlhttprequest-ssl' package has been copied in the contrib/ directory, until the change is merged upstream Related: #653
|
Closed by 6551683 and included in |
|
@darrachequesne Is there a linked PR to upstream the https://github.com/mjwwit/node-XMLHttpRequest? A quick glance suggests that this import mechanism causes a lot of transitive dependencies on socket.io to break in certain exotic environments, like codesandbox.io. (See codesandbox/codesandbox-client#4456 (comment)) |
|
@shaoster sure, please do 👍 |
|
mjwwit/node-XMLHttpRequest#9 (comment) has been merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm opening this issue to discuss a PR I put up three weeks ago. Perhaps some community discussion is more appropriate/likely here than there?
Is your feature request related to a problem? Please describe.
If the
closeAPI isn't used, then the transport layer leaves some things around that will prevent the event loop from exiting. This is problematic when you are creating a library that uses socket.io under the hood and your user fails to let you know explicitly they are done messaging (something I'd really like to support, especially since it can be hard to find out why your program isn't exiting and hard to communicate that it might be because they failed to callclose).Describe the solution you'd like
I can understand why sometimes the desired behavior would be precisely to keep the program from exiting since you're not done with your socket io client! But in my case, it'd be great to have an option that is analogous to the
unrefAPI provided for timers, sockets, servers, and the like in core Node (links in the PR: #652)Also, I ended up bumping into a related issue in the
socket.io-clientpackage and found it could use the same option to get the same effect: socketio/socket.io-client#1442.Describe alternatives you've considered
I described some alternatives in a related issue on the
socket.io-clientrepo: socketio/socket.io-client#1446. Basically it seems my only options are to either spawn a child process or just accept that theclosemethod needs to be called.Additional context
#652
The text was updated successfully, but these errors were encountered: