On 28/06/2017 01:57, Alistair Francis wrote:
> + /* We only found one and we are waiting on more then one. Let's try
> + * again.
> */
> - if (timeout == 0 && nhandles > 1) {
> + if (nhandles > 1) {
> /* Remove the handle that fired */
> int i;
> if ((ready - WAIT_OBJECT_0) < nhandles - 1) {
> @@ -444,7 +444,20 @@ static int poll_rest(gboolean poll_msgs, HANDLE
> *handles, gint nhandles,
> }
> }
> nhandles--;
> - recursed_result = poll_rest(FALSE, handles, nhandles, fds, nfds,
> 0);
> +
> + /* If we just had a very small timeout let's increase it when we
> + * recurse to ensure we don't just busy wait. This ensures we let
> + * the Windows threads block at least a little. If we previously
> + * had some wait let's set it to zero to avoid blocking for too
> + * long.
> + */
> + if (timeout < 10) {
> + timeout = timeout + 1;
> + } else {
> + timeout = 0;
> + }
> + recursed_result = poll_rest(FALSE, handles, nhandles, fds,
> + nfds, timeout);
> return (recursed_result == -1) ? -1 : 1 + recursed_result;
I'm not sure I agree with this change, which is effectively delaying the
processing of events. The question to me is which handles are
triggering so fast that QEMU effectively busy waits.
Maybe your QEMUs can get some breath with commit 12f8def0e0 ("win32:
replace custom mutex and condition variable with native primitives",
2017-03-27), since the native primitives are more efficient and TCG 2.8
used condvars a lot for qemu_io_proceeded_cond.
Paolo
