From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvdZy-0000Vt-QG for qemu-devel@nongnu.org; Wed, 07 Oct 2009 16:57:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvdZu-0000QV-Sc for qemu-devel@nongnu.org; Wed, 07 Oct 2009 16:57:46 -0400 Received: from [199.232.76.173] (port=47590 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvdZu-0000Q4-M2 for qemu-devel@nongnu.org; Wed, 07 Oct 2009 16:57:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55654) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvdZu-0004Nj-3o for qemu-devel@nongnu.org; Wed, 07 Oct 2009 16:57:42 -0400 Date: Wed, 7 Oct 2009 22:55:23 +0200 From: "Michael S. Tsirkin" Message-ID: <20091007205523.GA4783@redhat.com> References: <20091007132006.GA9668@redhat.com> <4ACCC1A5.5020306@codemonkey.ws> <20091007204421.GC4085@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: [PATCH] Revert "posix-aio-compat: avoid signal race when spawning a thread" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org On Thu, Oct 08, 2009 at 12:54:00AM +0400, malc wrote: > On Wed, 7 Oct 2009, Michael S. Tsirkin wrote: > > > On Wed, Oct 07, 2009 at 11:28:21AM -0500, Anthony Liguori wrote: > > > > > >> There's nothing to review in this particular case, the thing was plain > > >> broken, besides same thing was already discussed between me and > > >> Andrzej, see for instance: > > >> http://www.mail-archive.com/qemu-devel@nongnu.org/msg09542.html > > >> > > >> Needless to say the revert is broken also. > > >> > > > > > > Yeah, I understand the race the original commit fixes but I don't > > > understand how the original commit broke WinXP. > > > > > > Do you have further insight Michael? > > > > My guess is that SIGALARM gets lost, this somehow leads to > > disk request to timeout. Possible? > > Being delayed - possible, being lost - violation of the spec. I see this: The use of sigprocmask() is unspecified in a multithreaded process; see pthread_sigmask(3). Does it matter? > > > > > Blindly reverting something that appears right because of a > > > regression is likely just papering over a bigger problem. > > > > > > Regards, > > > > > > Anthony Liguori > > > > > > > -- > mailto:av1474@comtv.ru