From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTz2l-0008Cz-A3 for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:03:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTz2c-0003at-QM for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:03:35 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:50097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTz2c-0003aM-Ku for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:03:26 -0400 Received: by mail-we0-f170.google.com with SMTP id u57so1376641wes.15 for ; Wed, 09 Oct 2013 12:03:25 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5255A878.7080702@redhat.com> Date: Wed, 09 Oct 2013 21:03:20 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1381259403-7386-1-git-send-email-hdegoede@redhat.com> <52545950.5070403@redhat.com> <52545B44.70005@redhat.com> <28EE4224-856B-4DC1-8159-A0C274BD269E@alex.org.uk> <52546000.6070308@redhat.com> <6CD4D4EE-341E-48D0-98F4-D55C0D3922D4@alex.org.uk> <52546832.9040900@redhat.com> <5254701B.5070804@redhat.com> <525552D9.90407@redhat.com> <2451DF8D-DD3E-4875-B6D6-CEF66A763D7E@alex.org.uk> <52559A8A.2070201@redhat.com> <30CAC247-C396-4991-804B-DD0A0FE68674@alex.org.uk> <5255A554.1070105@redhat.com> In-Reply-To: <5255A554.1070105@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org, Alex Bligh Il 09/10/2013 20:49, Hans de Goede ha scritto: >> >> I wonder whether it's meant to be 1 millisecond or 1 microsecond? > > Maybe once it was 1 ms, this code just exists to keep the buffers > of a soundcard filled / emptied in time. 100 times / second is more > then plenty for that, so that is what I'm going to use in the patch I'm > about to submit. It was 1 ms when that was the resolution of the "alarm tick" (which was based on /dev/rtc or /dev/hpet), then it became 250 us with "dynamic ticks", then we know how it became 0 (1 ns after timer_mod is effectively 0 ns after select). Paolo