Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

honor ErrorKind::Interrupted in write_all()? #611

Open
rmja opened this issue Jul 4, 2024 · 4 comments
Open

honor ErrorKind::Interrupted in write_all()? #611

rmja opened this issue Jul 4, 2024 · 4 comments

Comments

@rmja
Copy link
Contributor

rmja commented Jul 4, 2024

Currently in write_all() (https://github.com/rust-embedded/embedded-hal/blob/master/embedded-io-async/src/lib.rs#L134) we do not retry if the return error has kind() == ErrorKind::Interrupted. This is different than std: https://doc.rust-lang.org/src/std/io/mod.rs.html#1696-1708.

Should ErrorKind::Interrupted lead to a silent retry in write_all()?

@eldruin
Copy link
Member

eldruin commented Jul 4, 2024

Interesting question.
I would ask then how often should it retry. Either we create an endless loop or we define an arbitrary number which will be difficult to agree upon.
Given the general character or e-io-async, I think the caller is better positioned to put a loop on the call in this case.

@Dirbaio
Copy link
Member

Dirbaio commented Jul 4, 2024

ErrorKind::Interrupted is annoying unix legacy-ish. I don't think anyone uses it intentionally anymore, especially now that async exists? it doesn't really exist on embedded, and i'd say it shouldn't exist.

So perhaps another option is to make embedded_io_adapters::FromStd do the retry on the write() method, so we keep Interrupted errors to the boundary of embedded-io instead of letting them in?

@rmja
Copy link
Contributor Author

rmja commented Jul 4, 2024

That sounds like a really good idea. Should we then also remove ErrorKind::Interrupted?

@Dirbaio
Copy link
Member

Dirbaio commented Jul 4, 2024

probably, yes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants