Add softer ReadMessage timeout mechanism that only cancels the operation and doesn't corrupt the entire connection

[Eelis]

Currently, as far as I can see, the only mechanism for getting a timeout on a ReadMessage call is by setting a read deadline with SetReadDeadline.

This works, but if a read times out due to a read deadline, the whole connection is corrupted and cannot be read from anymore(!).

This is a surprising and extremely severe result that makes the mechanism unsuitable when all you really want is to just try receiving for a while, and if no message was received, then go do other stuff, and re-try receiving on the same (intact) connection later. As far as I can tell (please correct me if I'm wrong), there is currently no way to do this, which is unfortunate.

That's correct. The connection methods use local variables to maintain state as is common with Go code. That state is lost of a connection method returns because of an error on the underlying connection. The connection is no longer useable after the state is lost. The connection methods could be written to be restorable, but that will take some effort.

The solution is to use a goroutine to go off and do other work. Because the application must read the connection to process control messages (documentation), it's not a good idea to go off and do other stuff for a long time.

[Eelis]

Yeah, in my use case the "other stuff" that I wanted to periodically do between ReadMessage calls was just a quick, non-blocking check to see if the component that consumes the messages is still interested in consuming more of them.

As an awkward workaround, I can have a separate goroutine that does the periodic checking and closes the websocket connection when the component isn't interested in consuming additional messages anymore, and then make sure I handle the resulting expected read errors specially. It would just be nicer if this awkward workaround with an additional goroutine and error handling wasn't necessary. :)

When the component is no longer interested in receiving messages, the application should send a close message to the peer. The peer will echo the message back and that message will be returned as an error from the websocket connection's read API. If you use websocket.CloseNormalClosure or some other expected error code, no special error handling should be required.

The application should force close the connection after a timeout to handle the case where the peer does not correctly echo the close message back to the application.

[Eelis]

@garyburd: Hmm, is it normal for you to close tickets without stating a reason? :) In any case, is it fair to conclude from stevenscott89's comment (quoted below) that the reason for closing the ticket is that not killing the connection on read timeouts is too hard in Go?

The connection methods use local variables to maintain state as is common with Go code. That state is lost of a connection method returns because of an error on the underlying connection. The connection is no longer useable after the state is lost. The connection methods could be written to be restorable, but that will take some effort.

[aspotashev]

This would be easy to implement if we had this feature -> #481