From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbCTe-0003zo-8I for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:44:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbCTd-0004Ly-6i for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:44:38 -0500 Received: from goliath.siemens.de ([192.35.17.28]:19321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbCTc-0004LY-Tf for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:44:37 -0500 Message-ID: <50ACF6DE.8030106@siemens.com> Date: Wed, 21 Nov 2012 16:44:30 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <50ACDE8F.5010507@siemens.com> <50ACE050.8050001@redhat.com> <50ACE564.9030204@siemens.com> <50ACE764.1070608@redhat.com> <50ACE9EB.6010208@siemens.com> In-Reply-To: <50ACE9EB.6010208@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] coroutine: Fix win32 variant for older mingw32 compilers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Stefan Weil , qemu-devel On 2012-11-21 15:49, Jan Kiszka wrote: > On 2012-11-21 15:38, Paolo Bonzini wrote: >> Il 21/11/2012 15:33, malc ha scritto: >>>>>>> Leaking leader is a bit bad, but it looks ok for 1.3. >>>>> >>>>> Hmm. A TLS destructor is apparently not available. Is there some "on >>>>> thread termination" callback mechanism on Windows? Didn't find one on >>>>> first glance. >>>>> >>> Dlls receive something like THREAD_DETTACH in it's startup routine or >>> something like that if my memory serves me. >> >> Only DLLs. >> >> But this sounds like deja-vu. I'm pretty sure in the past we just >> decided that this compiler is not supported (of course it's bad that >> it's silent). Stefan, do you remember the details? > > Current Debian delivers 4.4-based mingw unfortunately. I think we practically do not leak, at least as long as we continue to use coroutines only over cpu and iothread context. Those threads stay as long as qemu is running. And to my understanding, those contexts are the only target of coroutines anyway. Anything that already uses its own proper threads has no need for this problematic concept, no? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux