Idea: new read method on std::io::Read trait that continues when interrupted

libs
1

It has happened now several times that I have needed a method that is something like a mix of the Read::read() and Read::read_exact() methods. What I want is to read up to N bytes from a Read object, and get less than N only if reaching EOF. The Read::read() method gets close, but can return an ErrorKind::Interrupted which means I have to try again. This is doable, but a bit inconvenient. The Read::read_exact() handles the Interrupted errors automatically, but if it reaches EOF you don't know what was written to the buffer, so you basically get nothing.

Is there interest to add a method that behaves like read(), but automatically retries when interrupted? It's just for convenience since the same can be accomplished by putting read() in a loop, but I think it's a common enough use case to make it worthwhile.

1 Like
2

Does SA_RESTART not handle this for you?

3

I'm not familiar with that, how would you use it?

4

I'm not familiar with [SA_RESTART]

Let's back up a step. Are you actually getting ErrorKind::Interrupted from Read::read in your program, or did you just see it in the documentation so now you're worried about it?

I ask because ErrorKind::Interrupted cannot happen unless you have set up the conditions for it, and in the process of learning how to set up those conditions, there's a good chance you would have heard of SA_RESTART. Do you use signal handlers in your program? (Is the term "signal handler" also unfamiliar?)

5

Yes I do. It's rare, but not so rare that I can just ignore it.

I use signal handlers to handle SIGINT and SIGHUP. I use signal-hook for that so haven't needed to look into the details.

6

What if I want to read() in a library? I don't know what applications the library may end up being used in, so I can't make any assumptions about the interrupted error being possible or not. The only safe option is to assume that it can happen, and that means I need to handle it. And