From 98c5ceb73f2d0b217ae7b8598d1a0ffe15bb26f4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= Date: Wed, 31 May 2023 13:15:13 +0300 Subject: [PATCH] ptp: On Windows handle socket polls that result in no error but also no FD_READ event According to the documentation this should never happen but apparently does under certain circumstances. As the sockets are set non-blocking, trying to read from them regardless should not cause any problems. In all cases that were observed so far, the socket in question actually has a packet queued up for reading. Part-of: --- subprojects/gstreamer/libs/gst/helpers/ptp/io.rs | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/subprojects/gstreamer/libs/gst/helpers/ptp/io.rs b/subprojects/gstreamer/libs/gst/helpers/ptp/io.rs index 1baefd6d2e..f42eaad07c 100644 --- a/subprojects/gstreamer/libs/gst/helpers/ptp/io.rs +++ b/subprojects/gstreamer/libs/gst/helpers/ptp/io.rs @@ -696,7 +696,17 @@ mod imp { if res == 0 { "event" } else { "general" }, ); } - assert!(networkevents.lnetworkevents & FD_READ != 0); + + // FIXME: This seems to happen every now and then although it shouldn't, and in + // that case a packet always seems to be queued up on the socket. As the sockets + // are non-blocking it also wouldn't be a problem otherwise, so let's just log this + // here and ignore it. + if networkevents.lnetworkevents & FD_READ == 0 { + debug!( + "Socket {} woke up but has neither an error nor a FD_READ event", + res + ); + } } Ok(PollResult {