Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

From: Aurelien Jarno <aurelien@aurel32.net>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	Paul Brook <paul@codesourcery.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Arun Bharadwaj <arun@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
Date: Mon, 7 Feb 2011 22:45:51 +0100	[thread overview]
Message-ID: <20110207214551.GB16429@hall.aurel32.net> (raw)
In-Reply-To: <4D505DCB.9050406@codemonkey.ws>

On Mon, Feb 07, 2011 at 03:02:03PM -0600, Anthony Liguori wrote:
> On 02/07/2011 11:10 AM, Jan Kiszka wrote:
>> On 2011-02-07 17:23, Paolo Bonzini wrote:
>>    
>>> On 02/07/2011 05:03 PM, Marcelo Tosatti wrote:
>>>      
>>>> Is there any other issue that prevents turning CONFIG_IOTHREAD on by
>>>> default?
>>>>        
>>> I think Windows support.
>>>
>>> Signal support is actually easy because we can "hack" the IPI as
>>> "suspend the VCPU thread+do work in the iothread context+resume the VCPU
>>> thread" (the IPI handler doesn't longjmp).
>>>
>>> Threading primitives support is tricky but not hard (there is lots of
>>> code around, especially if you can make assumptions such as "always hold
>>> the mutex while signaling a cond. variable").
>>>      
>> !CONFIG_IOTHREAD code is doomed to bitrot once we switch to default
>> iothread mode. So if Windows support is not converted to a threading
>> model with moderate differences to POSIX, it will likely bitrot a well.
>> Therefore, conversion should be started rather sooner than later (by
>> someone interested in that platform).
>>    
>
> As far as I'm concerned, Windows support is already deprecated as noone  
> has stepped up to enhance it or support for a number of years now.  We  
> shouldn't remove existing code that supports it or refuse to take  
> reasonable patches but if enabling IO thread by default breaks it, so be 
> it.

As far as I see, Blue Swirl and Stefan Weil are regularly committing
fixes for win32. Stefan Weil is also providing win32 binaries on his
website [1]. I wouldn't call that deprecated.

[1] http://qemu.weilnetz.de/

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net