From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7806 invoked by alias); 19 Feb 2015 11:00:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7793 invoked by uid 89); 19 Feb 2015 11:00:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 19 Feb 2015 11:00:22 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1JB0INd004774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Feb 2015 06:00:19 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1JB0HMP019975; Thu, 19 Feb 2015 06:00:17 -0500 Message-ID: <54E5C240.2020801@redhat.com> Date: Thu, 19 Feb 2015 11:00:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Patrick Palka CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] Asynchronously resize the TUI References: <1424219777-12138-1-git-send-email-patrick@parcs.ath.cx> <54E4629A.5050400@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00522.txt.bz2 On 02/19/2015 12:03 AM, Patrick Palka wrote: > Thanks for reviewing. I have committed the patch in two pieces > because I forgot to add the gdb/ChangeLog entry in the first commit. > Sorry about that... No worries. > BTW shouldn't the object returned by create_async_signal_handler() be > eventually deallocated via delete_async_event_handler() at some point? > It doesn't seem that we do this for any async signal handler > currently in use so far.. Yeah, that's not really different from all the global objects that are allocated on the heap, and aren't ever deleted. They'll just go away when GDB exits along with the heap. For a proper GDB-as-a-library use case though, we'd/we'll probably need to consider this. Thanks, Pedro Alves