All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, ming.lei@canonical.com, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 5/7] coroutine: rewrite pool to avoid mutex
Date: Tue, 02 Dec 2014 13:32:21 +0100	[thread overview]
Message-ID: <547DB155.4010405@redhat.com> (raw)
In-Reply-To: <547DAE27.7050306@kamp.de>



On 02/12/2014 13:18, Peter Lieven wrote:
> On 02.12.2014 13:13, Paolo Bonzini wrote:
>>
>> On 02/12/2014 13:09, Peter Lieven wrote:
>>>> -static void __attribute__((destructor)) coroutine_pool_cleanup(void)
>>>> -{
>>>> -    Coroutine *co;
>>>> -    Coroutine *tmp;
>>>> -
>>>> -    QSLIST_FOREACH_SAFE(co, &pool, pool_next, tmp) {
>>>> -        QSLIST_REMOVE_HEAD(&pool, pool_next);
>>>> -        qemu_coroutine_delete(co);
>>>> -    }
>>>> -
>>>> -    qemu_mutex_destroy(&pool_lock);
>>>> -}
>>>> -
>>> I still feel we should leave this destructor in to clean up the
>>> release_pool.
>> Why?  If you run QEMU under valgrind, there are thousands of blocks that
>> we do not free.  Stefan/Kevin, what do you think?
> 
> Before this patch we cleaned up this part at least.
> I have learned that it bad style not to clean up your resources.
> Just because other code parts do not do it we should not introduce
> new parts that don't it.

Which other parts do we cleanup?  For example file descriptors are not
cleaned up, much less most memory; the kernel is there to do it for us.
 I think it's up to the maintainers to decide.

Paolo

  reply	other threads:[~2014-12-02 12:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-02 11:05 [Qemu-devel] [PATCH v2 0/7] coroutine: optimizations Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 1/7] coroutine-ucontext: use __thread Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 2/7] qemu-thread: add per-thread atexit functions Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 3/7] test-coroutine: avoid overflow on 32-bit systems Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 4/7] QSLIST: add lock-free operations Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 5/7] coroutine: rewrite pool to avoid mutex Paolo Bonzini
2014-12-02 12:09   ` Peter Lieven
2014-12-02 12:13     ` Paolo Bonzini
2014-12-02 12:18       ` Peter Lieven
2014-12-02 12:32         ` Paolo Bonzini [this message]
2014-12-02 13:04       ` Kevin Wolf
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 6/7] coroutine: drop qemu_coroutine_adjust_pool_size Paolo Bonzini
2014-12-02 11:05 ` [Qemu-devel] [PATCH v2 7/7] coroutine: try harder not to delete coroutines Paolo Bonzini
2014-12-11 13:55 ` [Qemu-devel] [PATCH v2 0/7] coroutine: optimizations Peter Lieven
2014-12-15 21:35   ` Paolo Bonzini
2014-12-18 10:06 ` Fam Zheng
2015-01-06 15:39 ` Stefan Hajnoczi

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=547DB155.4010405@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=ming.lei@canonical.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.