From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7McL-0001Hz-8r for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:43:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7McI-0005DY-0L for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:43:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7McH-0005DB-QZ for qemu-devel@nongnu.org; Tue, 23 Jun 2015 07:43:49 -0400 Date: Tue, 23 Jun 2015 12:43:44 +0100 From: "Daniel P. Berrange" Message-ID: <20150623114344.GF30318@redhat.com> References: <1435010055-4584-1-git-send-email-zavadovsky.yan@gmail.com> <5588F689.8050202@weilnetz.de> <55893923.9010304@redhat.com> <20150623111822.GE30318@redhat.com> <558943C3.9030709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <558943C3.9030709@redhat.com> Subject: Re: [Qemu-devel] [PATCH] thread-win32: fix GetThreadContext() permanently fails Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Olivier Hainque , Peter Maydell , =?utf-8?B?0K/QvSDQl9Cw0LLQsNC00L7QstGB0LrQuNC5?= , Stefan Weil , QEMU Developers , Fabien Chouteau On Tue, Jun 23, 2015 at 01:32:19PM +0200, Paolo Bonzini wrote: > > > 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. Are you sure that was wrt the (new) winpthreads library maintained by Mingw64 team, and not the confusingly similar pthreads-win32 library ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|