From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvmdJ-0000Uk-M9 for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:32:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvmdD-0000Lo-HR for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:32:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvmdD-0000LB-AG for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:32:39 -0500 Message-ID: <547DB155.4010405@redhat.com> Date: Tue, 02 Dec 2014 13:32:21 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1417518350-6167-1-git-send-email-pbonzini@redhat.com> <1417518350-6167-6-git-send-email-pbonzini@redhat.com> <547DABDE.2050009@kamp.de> <547DACF9.2090106@redhat.com> <547DAE27.7050306@kamp.de> In-Reply-To: <547DAE27.7050306@kamp.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 5/7] coroutine: rewrite pool to avoid mutex List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu-devel@nongnu.org Cc: kwolf@redhat.com, ming.lei@canonical.com, stefanha@redhat.com 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