qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for t


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev, broke CloudStack
Date: Fri, 17 Jul 2015 04:22:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1


On 17/07/2015 00:51, Nils Carlson wrote:
> 
> The commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev,
> broke CloudStack. CloudStack was relying on fire-and-forget style
> messaging across a unix socket to the VM. Because the host "fires" the
> message and then closes the socket a HUP is present on the line when the
> VM starts reading the socket. Commit 812c1057f ensured that the socket
> was checked for a HUP prior to calling recv, causing recv never to be
> called by the VM and no data to be read.
> 
> I've posted a patch, attached here, which moves the HUP detection to
> after all data has been read, but only for Linux as I suspect windows
> requires HUPs to be detected prior to reading data.

I'm not sure, but I don't think this is the case.  Why do you think
Windows has this requirement?  In any case, you should prepare a patch
that has no Windows-specific paths and Cc Kirill Batuzov
(address@hidden) for him to test the patch.

Alternatively I or you could test under Wine.

> Amit also has concerns regarding the return values from the tcp_chr_read
> function, which seem a bit odd as they are all TRUE, even for failure
> paths.

This is okay, I think, because the source is removed in tcp_chr_disconnect.

Paolo



reply via email to

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