On Thu, Apr 28, 2022 at 02:52:45PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 28, 2022 at 06:39:42AM -0700, Andrea Bolognani wrote: > > Shouldn't GLib be > > changed to do something like > > > > #ifndef BROKEN_POLL > > if (poll() < 0) > > if (!POLLNVAL) > > return -1; > > That's not the way POLLNVAL works - this is an even that is set in > each 'struct pollfd', so it is associated with individual file > descriptors. The application code can thus receive and handle the > G_IO_NVAL condition - it isn't fatal from POV of g_poll Right, I might have oversimplified things :) But your correction made the situation clearer in my head, thanks! > > #else > > if (select() < 0) > > if (!EBADF) > > return -1; > > #endif > > > > > instead? If acting on an fd that's already been closed is okay when > > using the poll()-based implementation, the same should apply to the > > select()-based one as well. > > The only way to get the same semantics for select() would be to see > EBADF and then iterate over struct pollfd, calling fcntl() to see > which one(s) are BADF. Possible, but its unpleasantly non-scalable, > so I imagine that's why they didn't do this. IIUC g_poll(), just like any other function used as GPollFunc, is supposed to have the same semantics as poll()[1], which means that passing an invalid FD should result in the corresponding flag being set rather than an outright failure. 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? [1] https://docs.gtk.org/glib/callback.PollFunc.html -- Andrea Bolognani / Red Hat / Virtualization
