From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Michael Snyder Cc: Don Howard , gdb-patches@sources.redhat.com Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost] Date: Tue, 18 Sep 2001 06:56:00 -0000 Message-id: <3BA7519F.70E25EC3@redhat.com> References: <3BA67BAA.825A5957@cygnus.com> X-SW-Source: 2001-09/msg00227.html Michael Snyder wrote: > > Don Howard wrote: > > > > [This is a repost with a few nits fixed, and addressed to the correct > > list =) ] > > > > Here is an other variation on how to deal with 'commands' scripts that > > delete their own breakpoint. The patch below makes a copy of the > > commands list before executing it and deletes the copy when finished. > > Comments? > > You mean other than "the concept makes my head hurt"? ;-) > > Well, let's see... seems like making a copy unconditionally > is going to slow down the execution of all command lists, > for the benefit of those few that delete themselves. > > Can we think of a way to make the duplication conditional > on the need? That is, on the current command list being > deleted? Put off the cost until it becomes necessary? > > I can think of one method, but it would require an extra pointer > in the breakpoint struct. "execute_control_command" would set > this pointer to point to its command list, and delete_breakpoint > would check the pointer. If it's non-null, then the duplication > would be done by delete_breakpoint, and the pointer updated to > point to the duplicate. > > Is it worth the effort? Is this duplication costly > compared to everything else already being done by > bpstat_do_actions? Or am I worrying over nothing? > I share your concerns. And I see no reason why this should be allowed -- the script can always "disable" its own breakpoint with the same effect for all practical purposes. A patch adding a "cannot delete self" error message would be nice. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9