Policy for `io::ErrorKind::Interrupted`

Is there a policy for handling io::ErrorKind::Interrupted in libstd? From what I can see, most (all?) nontrivial functions just ignore it and retry.

That’s a bit unfortunate. I find myself reimplementing half of std::io just to be able to interrupt those calls.

IMO the policy should be one of the following:

  1. Remove io::ErrorKind::Interrupted alltogether. (Even for read and write)
  2. (Preferred) Break on io::ErrorKind::Interrupted if possible. (Meaning if the function can be retried safely)

The current state is a bit pointless. The error is there and has to be considered, but it’s still not really usable for those who need it.

EDIT: An example of a function that could be retried safely is io::Read::read_to_end(...)

1 Like

The IO reform RFC covers the policy around read interruption.

Thanks for the pointer.

I don’t really agree with the reasoning… signals are not the only use case for interruption. There’s also explicit interruption e.g. with an adapter on top of existing Read implementations.

I agree that EINTR is a a nuisance if you don’t explicitly want to deal with it. But if you have to, you suddenly also have to deal with lots of code that doesn’t handle it “correctly”.

But it’s too late now for changes anyway. I guess I have to bite the bullet and write everything myself instead of using std. :disappointed:

I hope you can write it as a library for other people who need this functionality as well. :slight_smile:

If it turns out to be worth publishing I’ll certainly do so.

There you go: https://crates.io/crates/netio/

Comments and feedback welcome!

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.