News for hackers. Stuff that matters.

A comment on Don't trust default timeouts. Parent comment

Re:Don't trust default timeouts by networkimprov on Saturday August 29, 2020 @03:33PM (#24318810)
The Rust filesystem API works (or once did) as I described. This can render an application unusable when trying a network filesystem or storage device that's unavailable.

https://github.com/rust-lang/rust/issues/11214

To support user intervention when a task takes longer than expected, all blocking syscalls should be interruptible.

[ Parent | on HN ]
Re:Don't trust default timeouts by Arnavion on Saturday August 29, 2020 @03:40PM (#24318860)
Linking to discussions from pre-1.0 does not help your assertion.

std::fs::File's impl of std::io::Read:

https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...

-> https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...

-> https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...

Again, as I said, it corresponds one-to-one with a call to the underlying read API. The retries for ErrorKind::Interrupted are done by higher abstractions like std::io::Read::read_exact, and they explicitly document that they do this.

https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...

[ Parent | on HN ]
Re:Don't trust default timeouts by networkimprov on Saturday August 29, 2020 @04:04PM (#24319022)
Apologies if I got this wrong, but you've linked read(), and I'm referring to mkdir() et al.

Have they taken out the EINTR retries which were added for the issue I linked?

[ Parent | on HN ]