[Top][All Lists]

[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: Nils Carlson
Subject: Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev, broke CloudStack
Date: Fri, 17 Jul 2015 19:26:21 +0200 (CEST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Fri, 17 Jul 2015, Kirill Batuzov wrote:
On Fri, 17 Jul 2015, 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

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.

Could you comment on the validity of this assumption? I would be really happy
to have this issue solved as it stops us from upgrading to later versions of

I do not think your assumption is valid. Original goal of commit 812c1057f was
to handle all conditions in one watch because glib implementation for
Windows does not support multiple watches on one channel. Any changes
regarding order in which conditions are checked were unintended. On the
other hand I do not know if in pre-812c1057f implementation (with
multiple watches) this order was something defined, implementation
defined or undefined.

Some time ago another solution for this problem was proposed but was
never commited unfortunately (slipped through the cracks?).

[PATCH v3] qemu-char: Do not disconnect when there's data for reading

My comments on why I think it's better to handle disconnects with POSIX
return values can be found in the discussion of the first version of the
patch above.


Can you verify that the above patch v3 solves your problem? I would really
prefer to use return values instead of GIOConditions. They are much more
reliable and better documented.

Sorry, didn't see your e-mail until now, so I just posted version 3 of my patch.

Yes, I can try the other patch as well, just give me some time.


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.

All feedback very much appreciated.

Best Regards,
Nils Carlson

reply via email to

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