From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbCe7-0001JP-NW for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:55:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbCdx-00088G-Rs for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:55:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbCdx-00087w-JY for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:55:17 -0500 Message-ID: <50ACF950.1050003@redhat.com> Date: Wed, 21 Nov 2012 16:54:56 +0100 From: Paolo Bonzini 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> <50ACF6DE.8030106@siemens.com> In-Reply-To: <50ACF6DE.8030106@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: Jan Kiszka Cc: Kevin Wolf , Stefan Weil , qemu-devel Il 21/11/2012 16:44, Jan Kiszka 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? Kind of... when Stefan (Hajnoczi) finishes the full version of virtio-blk dataplane, there will be one thread per device running coroutines. But it's still a minor leak, it's ok for 1.3 and we can get it right later using the Windows run-time linker's TLS support, like on Linux. Paolo