-
Notifications
You must be signed in to change notification settings - Fork 13
Allow setting timeout for blocking remote calls #113
Comments
Thanks for pointing out. I didn't think of that. I think we should be OK though as long as our own code takes care of that (i-e if time-out is set, return the appropriate error to user instead of trying again implicitly) and we document this behavior. Correct? |
In GitLab by @codido on Nov 18, 2020, 22:45 This is certainly a valid approach, but one thing to keep in mind is that the current API lets users set or get the socket directly. So figuring out if a socket is blocking or non-blocking based on the potential timeout calls might break if someone does something like:
..or even just sets the timeout before passing the socket to ClientHandshake to begin with. |
Right but we don't have to rely on the timeout event but can check it directly from the socket itself. |
Oops, you were talking about blocking vs. non-blocking. Why would a timeout result in |
In GitLab by @codido on Nov 19, 2020, 01:27 That's the documented behaviour it seems, as documented for SO_RCVTIMEO and SO_SNDTIMEO: |
In GitLab by @be on Mar 31, 2022, 03:55 This came up in dark-light: frewsxcv/rust-dark-light#17 |
This will be mainly
Probably best we have a timeout on the whole
Connection
itself and add a getter/setter for timeout instead of adding_timeout
variants of these methods.Notes for implementor
There are setters for timeouts in std that you can make use of. Sincestd
crate separates read and write timeouts, it'd make sense for us to do the same I think.Update: now that our primary API is async and both tokio and async-io provide an easy way to add timeouts to async calls, this becomes much easier.
The text was updated successfully, but these errors were encountered: