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, Ян Завадовский <zavadovsky....@gmail.com> wrote: > >> On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil <s...@weilnetz.de> 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 :|
