On Fri, Apr 29, 2022 at 01:05:42AM -0700, Andrea Bolognani wrote:
On Thu, Apr 28, 2022 at 05:55:41PM +0100, Daniel P. Berrangé wrote:On Thu, Apr 28, 2022 at 08:33:46AM -0700, Andrea Bolognani wrote: > In other words, the current implementation of g_poll() on macOS > doesn't follow the contract defined by GLib itself. It seems to me > that this is a (fairly serious) bug in the library, no? It is significant, but long standing. GLib actually had this behaviour forever on macOS, but it regressed when Meson was introduced, until the recent fix. The question is whether efficiency trumps API semantics. Normally I'm heavily biased towards API semantics, but poll is a performance critical API, so it isn't so easy to declare we must workaround all the quirks. I filed a bug to raise the subject for discussion though https://gitlab.gnome.org/GNOME/glib/-/issues/2644That's an excellent bug report! Thanks for spending time on it, and let's see where the upstream discussion leads :)
Just so I don't sway the potential discussion in the issue to the wrong way, I'll ask here. Since BROKEN_POLL is used due to poll() on OS/X not behaving correctly with fds=NULL, nfds=0 [0], wouldn't it be possible to "fix" at least the internal calls to g_poll() which are done when running the main loop since they always have at least one FD (the eventfd used to signal the main loop [1])? I know it would not fix the problem, but it would at least workaround the part that is used the most, I presume. Martin [0] https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gpoll.c#L59 [1] this is a presumption I did not find in the code, but I've seen in gdb and strace
Attachment:
signature.asc
Description: PGP signature
