From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:50121)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RLgrT-0006w4-4p
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:52:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RLgrR-0004Lf-SP
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:52:34 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54310)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RLgrR-0004LZ-DZ
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:52:33 -0400
Message-ID: <4EB19F6B.8020907@redhat.com>
Date: Wed, 02 Nov 2011 20:52:11 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <4EB1640F.2090604@adacore.com> <j8rqt1$mc2$1@dough.gmane.org>
	<4EB1796B.7050901@adacore.com>
	<alpine.LNX.2.00.1111022115290.2177@linmac>
	<4EB181C4.1090501@redhat.com>
	<CAFEAcA_rJdNtOv5UJxks560W4pF4Sqk=wR6Zr90Y0Tyyy6W-XA@mail.gmail.com>
In-Reply-To: <CAFEAcA_rJdNtOv5UJxks560W4pF4Sqk=wR6Zr90Y0Tyyy6W-XA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Multiple instances of Qemu on Windows multicore
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Fabien Chouteau <chouteau@adacore.com>

On 11/02/2011 07:01 PM, Peter Maydell wrote:
> On 2 November 2011 17:45, Paolo Bonzini<pbonzini@redhat.com>  wrote:
>> The rest is always done in the iothread.  The iothread will then
>> suspend/resume the VCPU thread around the unchaining, so what matters is (in
>> Unix parlance) signal-safety of the unchaining, not thread-safety.
>
> The unchaining is neither signal-safe nor thread-safe...

Yeah, but there's nothing Windows-specific in that.

(Also, the unchaining is safer, or even completely safe in system mode 
than it is with pthreads).

Paolo