On Fri, 17 Jul 2015, Nils Carlson wrote:
Hi,
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.
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
qemu.
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
https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg03857.html
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.
https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg03261.html
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.