I/O timeouts implemented as deadlines is probably the wrong paradigm

[bill-myers]

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.

[emberian]

cc @alexcrichton @thestinger

[steveklabnik]

Today, the IO RFC is handling these kinds of issues. If you still care about this, I suggest getting involved in that conversation.

[thestinger]

It's genuinely broken / unusable and I don't see any RFC open about this. It was brought up in the original RFC but was ignored and implemented anyway, so clearly the input isn't welcome.

[aturon]

@thestinger I don't know what original RFC you're referring to, but there's a currently open RFC discussing these topics for the IO revamp.