[libvirt] mingw: virsh event loop failure in current git

[Eric Blake]

On 03/15/2011 05:02 AM, Daniel P. Berrange wrote:
> On Tue, Mar 15, 2011 at 09:29:14AM +0100, Matthias Bolte wrote:
>> Commit 2ed6cc7bec41dd344d41ea1531f6760c93099128 "Expose event loop
>> implementation as a public API" turned a failure to initialize the
>> default event loop into a fatal error in virsh on Windows. Before that
>> commit such a failure was ignored.
>>
>> virEventRegisterDefaultImpl calls virEventPollInit that calls
>> virSetNonBlock that calls ioctl that is replaced by gnulib and calls
>> ioctlsocket. ioctlsocket fails because the given FD is a pipe but
>> ioctlsocket expects a socket.
> 
> Hmm, isn't this actually a bug in gnulib's ioctl replacement then ?

Not necessarily.  FIONBIO is not a standardized ioctl() call (for that
matter, ioctl() is only standardized for STREAMS, which is an obsolete
Solaris concept not really supported in Linux).  Rather, the gnulib
ioctl() wrapper exists so you can call undo the rest of gnulib's munging
of mingw socket fds, since the real mingw ioctl() has to operate on the
socket rather than the (nicer) fd.

> The goal of gnulib is that you never use a SOCKET in any of the
> POSIX APIs it wraps. It hides the WinSock horribleness so that you
> can just use normal FDs everywhere.

But use of ioctl() is already non-portable; so a better solution would
be one that reduces the amount of direct ioctl in gnulib in the first
place (well, some ioctls are necessary, like lxc or kvm startup, but
that's in Linux-specific code and not expected to be portable elsewhere,
when contrasted with this bug report about the use of ioctl() in the
main generic polling loop).

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110328/8ce37ef5/attachment-0001.sig>