Hi On Thu, Dec 17, 2020 at 3:47 PM Paolo Bonzini <[email protected]> wrote:
> On 17/12/20 12:32, Claudio Fontana wrote: > > Is the root cause elsewhere though? > > > > I don't like stubs very much, because often they are introduced as the > easy way out of a problem instead of doing the necessary refactoring, > > and they end up confusing the hell out of someone trying to understand > what is actually used where, never mind trying to debug the linker errors. > > > > There is already an bunch of #ifndef _WIN32, #else , ... in > util/main-loop.c (quite a bunch of them really), > > is that what actually needs reworking, and putting the pieces together > in the build system in a way that makes sense? > > qemu_fd_register is almost not needed at all, since we have > > WSAEventSelect(node->pfd.fd, event, bitmask); > > in aio_set_fd_handler. I think we can remove the call to > qemu_fd_register from qemu_try_set_nonblock, and that should fix the > issue as well. > That's tricky to say whether this won't introduce regression. For most fds from qemu, if they use aio_set_fd_handler, that should be ok. But what about other fds? For examples, the ones from slirp? In fact, I don't understand how it could work today. We are passing socket() fd directly to g_poll(). But according to the documentation: * On Win32, the fd in a GPollFD should be Win32 HANDLE (*not* a file * descriptor as provided by the C runtime) that can be used by * MsgWaitForMultipleObjects. This does *not* include file handles * from CreateFile, SOCKETs, nor pipe handles. (But you can use * WSAEventSelect to signal events when a SOCKET is readable). And MsgWaitForMultipleObjects doesn't mention SOCKET as being valid handles to wait for. But when I run qemu with slirp, with or without qemu_fd_register, I don't see any error or regression. Am I missing something?
