From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7MRK-0007Xm-0E for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:32:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7MRF-0000j6-1E for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:32:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7MRE-0000j0-S7 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:32:24 -0400 Message-ID: <558943C3.9030709@redhat.com> Date: Tue, 23 Jun 2015 13:32:19 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1435010055-4584-1-git-send-email-zavadovsky.yan@gmail.com> <5588F689.8050202@weilnetz.de> <55893923.9010304@redhat.com> <20150623111822.GE30318@redhat.com> In-Reply-To: <20150623111822.GE30318@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] thread-win32: fix GetThreadContext() permanently fails List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Olivier Hainque , Peter Maydell , =?UTF-8?B?0K/QvSDQl9Cw0LLQsA==?= =?UTF-8?B?0LTQvtCy0YHQutC40Lk=?= , Stefan Weil , QEMU Developers , Fabien Chouteau On 23/06/2015 13:18, Daniel P. Berrange wrote: > > For 2.5, however, I wonder if SuspendThread/ResumeThread is needed at > > all now that cpu_exit doesn't have to undo block chaining anymore. Even > > on POSIX platforms the signal might not be necessary anymore. > > If you don't have that signal / SuspendThread/ResumtThread requirement, That was independent of QEMU reinventing the wheel for mutexes/condvars. > might that enable QEMU to just depend on the winpthreads library that > is provided by Mingw project, and not bother reinventing the wheel for > thread library portabilty ? We can and should just reuse glib these days as much as we can (probably not entirely because glib doesn't have detached threads). At least a few years ago, winpthreads was much slower than native Win32, which is why everyone reinvents the wheel. I was planning to do it in 2.5. Paolo