On Fri, Feb 11, 2011 at 2:28 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 02/10/2011 08:46 PM, Stefan Weil wrote: >> >> Am 10.02.2011 18:37, schrieb Paolo Bonzini: >>> >>> For now, qemu_cond_timedwait and qemu_mutex_timedlock are left as >>> POSIX-only functions. They can be removed later, once the patches >>> that remove their uses are in. >>> >>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> >>> Cc: Stefan Weil <w...@mail.berlios.de> >>> Cc: Blue Swirl <blauwir...@gmail.com> >>> --- >>> Makefile.objs | 4 +- >>> qemu-thread.c => qemu-thread-posix.c | 0 >>> qemu-thread-posix.h | 18 +++ >>> qemu-thread-win32.c | 272 ++++++++++++++++++++++++++++++++++ >>> qemu-thread-win32.h | 22 +++ >>> qemu-thread.h | 27 ++-- >>> 6 files changed, 326 insertions(+), 17 deletions(-) >>> rename qemu-thread.c => qemu-thread-posix.c (100%) >>> create mode 100644 qemu-thread-posix.h >>> create mode 100644 qemu-thread-win32.c >>> create mode 100644 qemu-thread-win32.h >>> >> >> What about using MinGW's pthread support? >> http://sourceforge.net/projects/mingw/files/MinGW/pthreads-w32/ >> >> I used it for the threaded vnc server in QEMU, but I don't >> have more practical experience with it. > > 1) For threads, we'd need to do the same in order to keep the HANDLE for > iothread IPIs (SuspendThread/ResumeThread). We could use nonportable > functions from pthread-w32, but if for example in the future QEMU switched > to glib these wouldn't be available. So QEMU would need a separate Win32 > implementation anyway sooner or later. > > 2) For condvars, we can make some more assumptions and make it > simpler/faster. > > 3) It has some namespace pollution issues. These wouldn't be a problem for > QEMU at the moment, however.
This patch no longer applies, please rebase.
