Re: [RFC] Patch for QUIT macro support

[Fred Fish <fnf@specifix.com>]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

On Sunday 15 October 2006 11:00, Mark Kettenis wrote:
> We really should not put history in our comments.

Good point.  Here is a patch with updated comments.

It would be good if someone could independently review, test, and
approve this, particularly anyone using an interface other than the
normal command line one.

-Fred



[-- Attachment #2: quit.diff --]
[-- Type: text/x-diff, Size: 1484 bytes --]

2007-01-22  Fred Fish  <fnf@specifix.com>

	* event-top.c (handle_sigint): Set quit_flag.
	(async_request_quit): Don't set quit_flag.  Avoid calling quit()
	if quit_flag has already been reset.

Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.48
diff -u -p -r1.48 event-top.c
--- event-top.c	9 Jan 2007 17:58:50 -0000	1.48
+++ event-top.c	22 Jan 2007 14:35:14 -0000
@@ -961,6 +961,13 @@ handle_sigint (int sig)
 {
   signal (sig, handle_sigint);
 
+  /* We could be running in a loop reading in symfiles or something so
+     it may be quite a while before we get back to the event loop.  So
+     set quit_flag to 1 here. Then if QUIT is called before we get to
+     the event loop, we will unwind as expected.  */
+
+  quit_flag = 1;
+
   /* If immediate_quit is set, we go ahead and process the SIGINT right
      away, even if we usually would defer this to the event loop. The
      assumption here is that it is safe to process ^C immediately if
@@ -989,7 +996,14 @@ handle_sigterm (int sig)
 void
 async_request_quit (gdb_client_data arg)
 {
-  quit_flag = 1;
+  /* If the quit_flag has gotten reset back to 0 by the time we get
+     back here, that means that an exception was thrown to unwind
+     the current command before we got back to the event loop.  So
+     there is no reason to call quit again here. */
+
+  if (quit_flag == 0)
+    return;
+
   quit ();
 }