[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOCh
From: |
Andrew Baumann |
Subject: |
Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32 |
Date: |
Fri, 11 Mar 2016 23:51:29 +0000 |
Hi folks,
> From: Paolo Bonzini [mailto:address@hidden
> Sent: Thursday, 10 March 2016 9:37 AM
>
> On 10/03/2016 18:26, Daniel P. Berrange wrote:
> > This series started out as an attempt to fix the Win32 problems
> > identified by Andrew Baumann
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg01343.html
> >
> > It turned into a significantly larger cleanup of some chardev
> > and osdep win32 portability code.
[...]
Sorry for chiming in a bit late here. I've tested these patches (the complete
set, not individually), and they do appear to fix my immediate problem: socket
char devices now work again. So thank you!
However, I'm now seeing a problem I don't believe we had before: very slow
responses to GDB commands. From looking at a packet capture (using a localhost
tcp socket between qemu and my gdb client), it seems that a couple of
operations will go through just fine, and then there is a 1 second delay
between my client's request and qemu's response. After fiddling with poll
timeouts, it became clear that we were noticing the socket events when waking
up from the poll, but the events themselves were still not waking us. It turns
out that we were not calling WSAEventSelect on the accept path. At least, the
following patch fixed the problem for me:
diff --git a/qemu-char.c b/qemu-char.c
index 3bf30b5..c1be622 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3047,6 +3047,7 @@ static gboolean tcp_chr_accept(QIOChannel *channel,
return TRUE;
}
+ qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
tcp_chr_new_client(chr, sioc);
object_unref(OBJECT(sioc));
However, I'd note that both callers of tcp_chr_new_client() make the same call
to set blocking to false immediately before calling tcp_chr_new_client().
Furthermore, the doc comment for qio_channel_set_blocking() appears to suggest
that non-blocking mode is the default. If that's true, maybe you don't even
want to rely on the caller explicitly setting blocking to false?
Cheers,
Andrew
- [Qemu-devel] [PATCH v2 09/18] io: pass HANDLE to g_source_add_poll on Win32, (continued)
- [Qemu-devel] [PATCH v2 09/18] io: pass HANDLE to g_source_add_poll on Win32, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 11/18] io: use qemu_accept to ensure SOCK_CLOEXEC is set, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 13/18] io: implement socket watch for win32 using WSAEventSelect+select, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 10/18] io: introduce qio_channel_create_socket_watch, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 14/18] char: remove qemu_chr_finish_socket_connection method, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 16/18] char: remove qemu_chr_open_socket_fd method, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 15/18] char: remove socket_try_connect method, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 18/18] osdep: remove use of socket_error() from all code, Daniel P. Berrange, 2016/03/10
- [Qemu-devel] [PATCH v2 17/18] osdep: add wrappers for socket functions, Daniel P. Berrange, 2016/03/10
- Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32, Paolo Bonzini, 2016/03/10
- Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32,
Andrew Baumann <=