Skip to content
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

Support for pervasive timeouts #315

Closed
reem opened this issue Feb 14, 2015 · 8 comments
Closed

Support for pervasive timeouts #315

reem opened this issue Feb 14, 2015 · 8 comments
Labels
A-client Area: client. A-server Area: server.

Comments

@reem
Copy link
Contributor

reem commented Feb 14, 2015

We need to provide timeouts for all of our blocking APIs and ways to set timeouts for all internal blocking actions.

@reem reem added A-server Area: server. A-client Area: client. labels Feb 14, 2015
@seanmonstar
Copy link
Member

Indeed, and we had a PR offering timeouts, but the IO reform currently means there is no API to do so for TcpStreams.

@reem
Copy link
Contributor Author

reem commented Apr 1, 2015

There is now going to be a stable way to timeout on condition variables, so we could implement something.

@seanmonstar
Copy link
Member

Link?

On Wed, Apr 1, 2015, 2:13 PM Jonathan Reem [email protected] wrote:

There is now going to be a stable way to timeout on condition variables,
so we could implement something.


Reply to this email directly or view it on GitHub
#315 (comment).

@reem
Copy link
Contributor Author

reem commented Apr 2, 2015

rust-lang/rust#23949

@seanmonstar
Copy link
Member

I see. So, to support a timeout using those, I imagine having to kick off 2 threads, one that is parked for X ms, the other that tries to read(), and we use a select! {} on the 2 receivers.

Doesn't sound cheap...

@seanmonstar seanmonstar modified the milestone: 1.0 Apr 27, 2015
@Wilfred
Copy link

Wilfred commented Jun 13, 2015

If you're not happy using select! in hyper itself, how about adding an example to the README? It took me a little fiddling to get it working, so having an example would have helped me.

@wezm
Copy link

wezm commented Jun 21, 2015

@seanmonstar
Copy link
Member

Yep! I'd like to try to start nowish on an API, and put it behind a Cargo feature timeouts. Then anyone could use it if they're using a nightly rustc, and we can maybe provide feedback after trying real use. I've just been busy on other parts, but PRs always welcome!

seanmonstar added a commit that referenced this issue Jul 27, 2015
While these methods are marked unstable in libstd, this is behind a
feature flag, `timeouts`. The Client and Server both have
`set_read_timeout` and `set_write_timeout` methods, that will affect all
connections with that entity.

BREAKING CHANGE: Any custom implementation of NetworkStream must now
  implement `set_read_timeout` and `set_write_timeout`, so those will
  break. Most users who only use the provided streams should work with
  no changes needed.

Closes #315
@seanmonstar seanmonstar removed this from the 1.0 milestone Dec 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-client Area: client. A-server Area: server.
Projects
None yet
Development

No branches or pull requests

4 participants