Description
The I/O library recently added timeout support, but implemented it in a very "peculiar" way.
In almost all libraries, specifying a timeout of T means that every operation will fail if more T is elapsed from the start of THAT operation.
In Rust instead, setting a timeout of T means that operations will fail if they terminate more than T time after the time the timeout was originally set.
So if you set a 1 second timeout, then after 1 second of time passes, all operations will instantly fail.
This is potentially useful if one wants to bound the time that a set of operations will take, but it seems unintuitive and inflexible in general.
Also, even if you reset the timeout before each operation, Rust's notion of timeouts includes userspace code and can thus cause timeouts due to preemption in the race window before the kernel is entered
It's probably a good idea to either implement timeouts normally (relative to the start of each operation), or perhaps add support for both normal relative timeouts, and absolute deadlines as implement in #13814 (taking the earliest of both, of course).
BTW, relative timeouts should probably be implemented with setsockopt(SO_RCVTIMEO/SO_SNDTIMEO) or similar facilities where possible in the libnative case, so that the number of system calls is reduced, and the kernel gets more information about what is being done.