device: Retry poll() on interrupts (EINTR)

[vilhelmbergsoe]

Attempt at handling EINTR in the case of a system call interrupt when polling for events.

Fixed an issue with a little program I wrote asciicam, which would panic with the error message "Error: Interrupted system call (os error 4)" when calling stream.next() after and upgrade from 0.13.0 -> 0.14.0.

I don't have a deep understanding of interruptible syscalls, but apparently the event polling from libv4l-rs is also connected to keyboard input in the terminal somehow?

While looking this up I came across a similar issue with crossterm here. They seem to have fixed it by continuing in the loop over polls, the PR is here.

This solution isn't as elegant as I just do a recursive call to poll and hope there isn't an interrupt next time, but it seems to work in my program.

[MarijnS95]

I think that makes sense, but a loop seems more clean than recursion IMO.

[vilhelmbergsoe]

I think that makes sense, but a loop seems more clean than recursion IMO.

Something like this, seem good to you?

[raymanfx]

IMO the best way to handle this is at the call site (i.e. your application). The EINTR error will be propagated all the way up by dequeue(), e.g. here for mmap:

libv4l-rs/src/io/mmap/stream.rs

Line 160 in 6a6017b

fn dequeue(&mut self) -> io::Result<usize> {

. If we do it anywhere in the library, it takes away the option for all users to interrupt the poll() call.

Perhaps I'm missing another aspect of this issue though; feel free to chime in in that case.

[matanox]

As I understand it, whenever EINTR is indicated in a syscall's return value, for example a poll, then whether within this crate's deque function or anywhere else at all, the interrupt had by that time been already fully handled before EINTR was raised to the code site doing the system call that was interrupted.

So interrupting the poll does not become impossible, but rather remains fully as possible, regardelss whether code is retrying a system call interrupted or not.

[matanox]

Upon initial AI-aided analysis of the logical state machine of releasing the buffers in the current codebase upon EINTR, it seems that letting the EINTR propagate, like it currently does, would place the MMAP module code in an unreliable state for the next upcoming cycles of calling next, and not just make it lose the frame which yielded the EINTR error result.