[Qemu-devel] Re: [PATCH 4/7] add win32 qemu-thread implementation

[Blue Swirl]

On Fri, Feb 11, 2011 at 2:28 PM, Paolo Bonzini <address@hidden> 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 <address@hidden>
>>> Cc: Stefan Weil <address@hidden>
>>> Cc: Blue Swirl <address@hidden>
>>> ---
>>> 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.