qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] thread-win32: fix GetThreadContext() permanentl


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] thread-win32: fix GetThreadContext() permanently fails
Date: Tue, 23 Jun 2015 12:18:22 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Jun 23, 2015 at 12:46:59PM +0200, Paolo Bonzini wrote:
> 
> 
> On 23/06/2015 12:30, Peter Maydell wrote:
> > On 23 June 2015 at 10:55, Ян Завадовский <address@hidden> wrote:
> >> On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil <address@hidden> wrote:
> >>> We should add an URL to reliable documentation which supports that
> >>> claim.
> >>
> >> Unfortunately, MSDN says only "SuspendThread suspends the thread. It's
> >> designed for debuggers. Don't use in applications.":
> >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms686345(v=vs.85).aspx
> >> And nothing more useful.
> >> So when I found this piece of code with Suspend/Resume and failed 
> >> GetContext
> >> I did some googling.
> >> And found this article:
> >> http://blogs.msdn.com/b/oldnewthing/archive/2015/02/05/10591215.aspx
> > 
> > Personally I am happy to treat a Raymond Chen blog post as "reliable
> > documentation"...
> 
> Me too. :)
> 
> SuspendThread was pretty much the only way to emulate signals.
> Initially I used SetThreadContext to redirect execution to cpu_signal;
> that was more complicated, but in retrospect it would have avoided the
> problems with memory barriers and with asynchronous SuspendThread.  It
> certainly would have saved the AdaCore people a lot of debugging time. :(
> 
> 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,
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 ?

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]