From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32397 invoked by alias); 28 May 2008 07:10:05 -0000 Received: (qmail 32346 invoked by uid 22791); 28 May 2008 07:10:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 May 2008 07:09:44 +0000 Received: (qmail 12100 invoked from network); 28 May 2008 07:09:42 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 May 2008 07:09:42 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [RFA] Use observers to report stop events. Date: Wed, 28 May 2008 18:30:00 -0000 User-Agent: KMail/1.9.9 Cc: Joel Brobecker , gdb-patches@sources.redhat.com References: <200804112145.58456.vladimir@codesourcery.com> <20080501195758.GL22218@caradoc.them.org> <200805041225.54416.vladimir@codesourcery.com> In-Reply-To: <200805041225.54416.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805281109.39277.vladimir@codesourcery.com> 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 X-SW-Source: 2008-05/txt/msg00728.txt.bz2 On Sunday 04 May 2008 12:25:54 Vladimir Prus wrote: > On Thursday 01 May 2008 23:57:58 Daniel Jacobowitz wrote: > > On Tue, Apr 29, 2008 at 10:10:30PM +0400, Vladimir Prus wrote: > > > Here are 3 independent bits. > > > > > > 1. Introduce the make_cleanup_restore_integer function. You're right > > > that it can lead to bad results if one discards this cleanup, but then > > > one should be careful with discarding cleanups anyway. > > > > This patch looks fine except that ... > > > > > 2. Modify the normal_stop observer not to fire in some cases. One > > > case is when doing function call -- we don't announce the stop in CLI > > > and for similar reason we don't have observer to be called. Also, > > > for the benefit of next patch, we want the call to observer to > > > be delayed until we print function return value, if we're doing finish. > > > > ... unless I'm mistaken you have exactly the memory leak Joel warned > > about, since finish_command discards continuations. > > > > Am I correct that the cleanup for finish_command is never supposed to > > survive the function returning? It's run on error and discarded on > > normal return. So you could put the closure in a local variable, > > maybe. > > > > struct foo_closure my_closure = { &my_global, my_global }; > > make_cleanup (restore_integer, &my_closure); > > This is somewhat limiting. Instead, I've implemented a mechanism that > allows a cleanup to well, "cleanup" its argument. I attach a patch > for that. > > I also attach a patch stop the 'finish_command_continuation' from > accessing a cleanup is has no business with. > > Are those two new patches, together with the previously posted one > (changing stop_observer not to always fire) OK? Ping? - Volodya