Open RichieSams opened 11 months ago
Interesting, I've never seen this use case before. But yes, you've got the idea right, you'd have to use time.AfterFunc with context.WithCancel. You wouldn't need to use atomics though, just cancel the timer after you get a reader. See the return value of time.AfterFunc.
Unfortunately I cannot suggest anything better nor do I think there's any good way to modify the API to accommodate this. Perhaps you might benefit from using the net.Conn adapter and use Set*Deadline to set the deadline more explicitly as you need to.
Thanks :)
Let's add an example for this though for sure.
Hi! Thanks for this excellent library.
I have a use case where I want the server to wait up to 10 seconds for the client to start sending data. If the server doesn't get a new Reader within that time, it closes the connection and bails.
However, if the client does start sending data, then they have a much longer time limit to finish sending. Say 2 minutes. As far as I can tell, there's not a good way to accomplish this with the current API design.
I saw this issue: https://github.com/nhooyr/websocket/issues/87
Which works IFF the idle timeout is larger than the read timeout.
This is because the
Conn.msgReader
holds on to the context passed in duringReader()
Example:I can potentially work around this. Instead of using
context.WithTimeout
, I could just usecontext.WithCancel
. Then have atime.AfterFunc()
, which uses atomics to check if we got the reader already. In which case, don't cancel. Example:I'm not sure what the best way to modify the API would be. You're unfortunately stuck with the io.Reader interface, without the ability to add a context. Thoughts?