[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [libvirt] mingw: virsh event loop failure in current git
Date: Mon, 28 Mar 2011 17:27:04 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9

[adding bug-gnulib and Paolo as author of rpl_ioctl]

On 03/15/2011 02:29 AM, 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.
> A version that works on pipes on Windows looks like this. Although the
> pipe is actually not a named pipe the call to SetNamedPipeHandleState
> doesn't fail at least.
> int
> virSetPipeNonBlock(int fd)
> {
>     DWORD mode = PIPE_NOWAIT;
>     HANDLE handle = _get_osfhandle(fd)
>     BOOL result = SetNamedPipeHandleState(handle, &mode, NULL, NULL);
>     return result ? 0 : -1;
> }
> So, is the event loop stuff supposed to work on Windows at all and we
> should get it fixed? Or do we just put an #ifndef WIN32 around
> virEventRegisterDefaultImpl in virsh, because the only event loop user
> in virsh is the console command that is disabled on Windows anyway?

Right now, gnulib's rpl_ioctl doesn't do any inspection of the various
requests handed it, nor does it check whether the request makes sense on
a non-socket.  Sniffing the FIONBIO request and handling it for pipes as
well as sockets might make sense.

And while gnulib has rpl_fcntl for mingw, it does not yet support
F_SETFL or F_GETFL to inspect/set O_NONBLOCK on non-file fds.  I'm not
sure how much effort that would be to add; I suppose that if F_GETFL
doesn't support all possible flags, but does support enough that we
could detect whether a read-modify-write F_GETFL/F_SETFL sequence is
trying to set or clear just O_NONBLOCK, that it would be sufficient for
the task at hand.

But rather than exposing fcntl, maybe the better thing to do is have
gnulib provide a simple wrapper API module that controls whether an fd
is blocking (similar to how the gnulib cloexec module hides
fcntl(F_GETFD/F_SETFD) or a mingw counterpart).

Paolo, any thoughts on the best approach to take?  (I know which way I'm
leaning, but want some feedback before I give away my bias).

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]