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?