qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Weil <weil@mail.berlios.de>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] coroutine: Fix win32 variant for older mingw32 compilers
Date: Wed, 21 Nov 2012 17:00:01 +0100	[thread overview]
Message-ID: <50ACFA81.9090209@siemens.com> (raw)
In-Reply-To: <50ACF950.1050003@redhat.com>

On 2012-11-21 16:54, Paolo Bonzini wrote:
> 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.

So it's a non-leak for current QEMU. :)

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-11-21 16:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-21 14:00 [Qemu-devel] [PATCH] coroutine: Fix win32 variant for older mingw32 compilers Jan Kiszka
2012-11-21 14:08 ` Paolo Bonzini
2012-11-21 14:29   ` Jan Kiszka
2012-11-21 14:33     ` malc
2012-11-21 14:38       ` Paolo Bonzini
2012-11-21 14:49         ` Jan Kiszka
2012-11-21 15:44           ` Jan Kiszka
2012-11-21 15:54             ` Paolo Bonzini
2012-11-21 16:00               ` Jan Kiszka [this message]
2012-11-21 19:11         ` Stefan Weil
2012-11-22  8:59           ` Paolo Bonzini
2012-11-22 12:07           ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50ACFA81.9090209@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weil@mail.berlios.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).