Various I/O operations need to have optional timeouts #13523

brson · 2014-04-15T00:05:09Z

Right now you just get whatever timeout the underlying OS decides to give you, and apparently it's very long (or maybe infinite). This is especially a problem for connect methods, where there's no object that can be forcibly closed from other threads.

TCP/unix connect std: Add timeouts to unix connect/accept #13723, std: Add an experimental connect_timeout function #13604
TCP/udp/unix read/write Read/write I/O timeouts #13814
TCP/unix accept std: Add support for an accept() timeout #13688,
Process wait io: Implement process wait timeouts #13957

The text was updated successfully, but these errors were encountered:

This adds a `TcpStream::connect_timeout` function in order to assist opening connections with a timeout (cc rust-lang#13523). There isn't really much design space for this specific operation (unlike timing out normal blocking reads/writes), so I am fairly confident that this is the correct interface for this function. The function is marked #[experimental] because it takes a u64 timeout argument, and the u64 type is likely to change in the future.

This adds a `TcpStream::connect_timeout` function in order to assist opening connections with a timeout (cc #13523). There isn't really much design space for this specific operation (unlike timing out normal blocking reads/writes), so I am fairly confident that this is the correct interface for this function. The function is marked #[experimental] because it takes a u64 timeout argument, and the u64 type is likely to change in the future.

This adds experimental support for timeouts when accepting sockets through `TcpAcceptor::accept`. This does not add a separate `accept_timeout` function, but rather it adds a `set_timeout` function instead. This second function is intended to be used as a hard deadline after which all accepts will never block and fail immediately. This idea was derived from Go's SetDeadline() methods. We do not currently have a robust time abstraction in the standard library, so I opted to have the argument be a relative time in millseconds into the future. I believe a more appropriate argument type is an absolute time, but this concept does not exist yet (this is also why the function is marked #[experimental]). The native support is built on select(), similarly to connect_timeout(), and the green support is based on channel select and a timer. cc rust-lang#13523

This adds support for connecting to a unix socket with a timeout (a named pipe on windows), and accepting a connection with a timeout. The goal is to bring unix pipes/named sockets back in line with TCP support for timeouts. Similarly to the TCP sockets, all methods are marked #[experimental] due to uncertainty about the type of the timeout argument. This internally involved a good bit of refactoring to share as much code as possible between TCP servers and pipe servers, but the core implementation did not change drastically as part of this commit. cc rust-lang#13523

This adds experimental support for timeouts when accepting sockets through `TcpAcceptor::accept`. This does not add a separate `accept_timeout` function, but rather it adds a `set_timeout` function instead. This second function is intended to be used as a hard deadline after which all accepts will never block and fail immediately. This idea was derived from Go's SetDeadline() methods. We do not currently have a robust time abstraction in the standard library, so I opted to have the argument be a relative time in millseconds into the future. I believe a more appropriate argument type is an absolute time, but this concept does not exist yet (this is also why the function is marked #[experimental]). The native support is built on select(), similarly to connect_timeout(), and the green support is based on channel select and a timer. cc rust-lang#13523

This adds experimental support for timeouts when accepting sockets through `TcpAcceptor::accept`. This does not add a separate `accept_timeout` function, but rather it adds a `set_timeout` function instead. This second function is intended to be used as a hard deadline after which all accepts will never block and fail immediately. This idea was derived from Go's SetDeadline() methods. We do not currently have a robust time abstraction in the standard library, so I opted to have the argument be a relative time in millseconds into the future. I believe a more appropriate argument type is an absolute time, but this concept does not exist yet (this is also why the function is marked #[experimental]). The native support is built on select(), similarly to connect_timeout(), and the green support is based on channel select and a timer. cc #13523

This implements set_timeout() for std::io::Process which will affect wait() operations on the process. This follows the same pattern as the rest of the timeouts emerging in std::io::net. The implementation was super easy for everything except libnative on unix (backwards from usual!), which required a good bit of signal handling. There's a doc comment explaining the strategy in libnative. Internally, this also required refactoring the "helper thread" implementation used by libnative to allow for an extra helper thread (not just the timer). This is a breaking change in terms of the io::Process API. It is now possible for wait() to fail, and subsequently wait_with_output(). These two functions now return IoResult<T> due to the fact that they can time out. Additionally, the wait_with_output() function has moved from taking `&mut self` to taking `self`. If a timeout occurs while waiting with output, the semantics are undesirable in almost all cases if attempting to re-wait on the process. Equivalent functionality can still be achieved by dealing with the output handles manually. [breaking-change] cc rust-lang#13523

This implements set_timeout() for std::io::Process which will affect wait() operations on the process. This follows the same pattern as the rest of the timeouts emerging in std::io::net. The implementation was super easy for everything except libnative on unix (backwards from usual!), which required a good bit of signal handling. There's a doc comment explaining the strategy in libnative. Internally, this also required refactoring the "helper thread" implementation used by libnative to allow for an extra helper thread (not just the timer). This is a breaking change in terms of the io::Process API. It is now possible for wait() to fail, and subsequently wait_with_output(). These two functions now return IoResult<T> due to the fact that they can time out. Additionally, the wait_with_output() function has moved from taking `&mut self` to taking `self`. If a timeout occurs while waiting with output, the semantics are undesirable in almost all cases if attempting to re-wait on the process. Equivalent functionality can still be achieved by dealing with the output handles manually. [breaking-change] cc #13523

This implements set_timeout() for std::io::Process which will affect wait() operations on the process. This follows the same pattern as the rest of the timeouts emerging in std::io::net. The implementation was super easy for everything except libnative on unix (backwards from usual!), which required a good bit of signal handling. There's a doc comment explaining the strategy in libnative. Internally, this also required refactoring the "helper thread" implementation used by libnative to allow for an extra helper thread (not just the timer). This is a breaking change in terms of the io::Process API. It is now possible for wait() to fail, and subsequently wait_with_output(). These two functions now return IoResult<T> due to the fact that they can time out. Additionally, the wait_with_output() function has moved from taking `&mut self` to taking `self`. If a timeout occurs while waiting with output, the semantics are undesirable in almost all cases if attempting to re-wait on the process. Equivalent functionality can still be achieved by dealing with the output handles manually. [breaking-change] cc rust-lang#13523

alexcrichton · 2014-05-14T07:16:40Z

Closing, all the ones I know of have been implemented. Specific issues of remaining ones should be opened up.

…=lnicola fix: disregard type variable expectation for if expressions Fixes rust-lang#13522 As [the comment](https://github.com/rust-lang/rust-analyzer/blob/8142d1f606dc2e52b1d2b8992671e2bd73379f28/crates/hir-ty/src/infer.rs#L1087-L1090) on `Expectation::adjust_for_branches` explains: > If the expected type is just a type variable, then don't use an expected type. Otherwise, we might write parts of the type when checking the 'then' block which are incompatible with the 'else' branch. Note that we already use it in match expressions. I've added tests for them too nevertheless.

brson added the A-libs label Apr 15, 2014

alexcrichton mentioned this issue Apr 18, 2014

std: Add an experimental connect_timeout function #13604

Merged

alexcrichton mentioned this issue Apr 22, 2014

std: Add support for an accept() timeout #13688

Merged

alexcrichton mentioned this issue Apr 24, 2014

std: Add timeouts to unix connect/accept #13723

Merged

alexcrichton closed this as completed May 14, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Various I/O operations need to have optional timeouts #13523

Various I/O operations need to have optional timeouts #13523

brson commented Apr 15, 2014

alexcrichton commented May 14, 2014

Various I/O operations need to have optional timeouts #13523

Various I/O operations need to have optional timeouts #13523

Comments

brson commented Apr 15, 2014

alexcrichton commented May 14, 2014