-
-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCPSocket specs hang if client doesn't connect #925
Comments
Good find, PR welcome. |
I think simply reversing the order of these and ignoring shutdown errors would be fine (or don't have the server's normal loop do its own close). |
If the server never accepts a client, joining on this thread will hang the spec and never be terminated because it happens in an "after" section. Instead, we try to close the server if it has not already been closed, so it will terminate gracefully. See ruby/spec#925
jruby/jruby@14945c6 doesn't quite work correctly.
and
So I will revert that commit when sync'ing to ruby/spec. I think in general we should not try too hard to avoid hangs in specs (when the Ruby impl misbehaves), because the |
If the server never accepts a client, joining on this thread will hang the spec and never be terminated because it happens in an "after" section. Instead, we try to close the server if it has not already been closed, so it will terminate gracefully. See #925
Thanks for fixing the typos. I had hoped to avoid swallowing errors during the I believe it should be expected of all Ruby specs that they can set up and tear down cleanly without any expectation that the spec body runs successfully. That is clearly not the case here, since numerous kinds of failures in the spec body will lead to the teardown logic hanging. That is not a timeout due to a bug, it is a timeout due to a badly written spec teardown. |
The TCPSocket#initialize specs will hang if the client socket does not connect to the server, since the shutdown for the server expects that it will have handled a request and be wrapping up here:
https://github.com/ruby/spec/blob/master/library/socket/fixtures/classes.rb#L125-L129
I found this while adding support for the new
connect_timeout
keyword; we do not support hash arguments on TCPSocket#initialize at the moment, so the socket never connects. This leaves the server waiting for an incoming connection, and the Thread#join above will hang the suite.Perhaps we should actively try to close the server socket before we join the thread, and ignore any errors on the thread from a double-close? It would allow these specs to be a bit more robust when there are errors setting up the TCPSocket before connection.
The text was updated successfully, but these errors were encountered: