On Tue, Sep 03, 2024 at 09:25:39PM +0200, Stefano Brivio wrote:On Tue, 3 Sep 2024 22:02:31 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote:My understanding is that EINTR means the system call was aborted because a signal handler happened during it. It usually doesn't matter why we got the signal - we still need to redo the system call and we might as well do so immediately.When tap_passt_input() gets an error from recv() it (correctly) does not print any error message for EINTR, EAGAIN or EWOULDBLOCK. However in all three cases it returns from the function. That makes sense for EAGAIN and EWOULDBLOCK, since we then want to wait for the next EPOLLIN event before trying again. For EINTR, however, it makes more sense to retry immediately - as it stands we're likely to get a renewer EPOLLIN event immediately in that case, since we're using level triggered signalling. So, handle EINTR separately by immediately retrying until we succeed or get a different type of error.I don't see an actual improvement: we don't know why we would get EINTR (because of signals) so repeating the recv() right away isn't necessarily a better choice.I'd say whatever way we have of carrying on on EINTR is fine. If this patch helps with brevity for the next ones, it makes sense, but otherwise I don't see a real advantage.Right. Specifically in order to use EPOLLET, I need to _not_ treat EINTR the same way as EAGAIN and EWOULDBLOCK.Well, it's more consistent with the way we handle EINTR on other calls, but that's about it.That too. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson