diff src/lisp.h @ 1123:37bdd24225ef

[xemacs-hg @ 2002-11-27 07:15:02 by ben] bug fixes, profiling debugging improvements configure.in: Check for GCC version and only use -Wpacked in v3. .cvsignore: Add .idb, .ilk for MS Windows VC++. cl-macs.el: Document better. cmdloop.el: Removed. Remove nonworking breakpoint-on-error now that debug-on-error works as documented. help.el: Extract out with-displaying-help-buffer into a more general mechanism. lib-complete.el: Support thunks in find-library-source-path. startup.el: Don't catch errors when noninteractive, because that makes stack traces from stack-trace-on-error useless. .cvsignore: Windows shit. alloc.c: Better redisplay-related assert. elhash.c: Comment change. eval.c: Don't generate large warning strings (e.g. backtraces) when they will be discarded. Implement debug-on-error as documented -- it will enter the debugger and crash when an uncaught signal happens noninteractively and we are --debug. Better redisplay-related asserts. frame-msw.c, frame.c, lisp.h, redisplay.c, scrollbar-gtk.c, scrollbar-x.c, signal.c, sysdep.c: Fix up documentation related to QUIT (which CANNOT garbage-collect under any circumstances), and to redisplay critical sections. lread.c: Add load-ignore-out-of-date-elc-files, load-always-display-messages, load-show-full-path-in-messages for more robust package compilation and debugging. profile.c: Overhaul profile code. Change format to include call count and be extensible for further info. Remove call-count-profile-table. Add set-profiling-info. See related profile.el changes (which SHOULD ABSOLUTELY be in the core! Get rid of xemacs-devel and xemacs-base packages *yesterday*!).
author ben
date Wed, 27 Nov 2002 07:15:36 +0000
parents 184461bc8de4
children e22b0213b713
line wrap: on
line diff
--- a/src/lisp.h	Tue Nov 26 22:52:59 2002 +0000
+++ b/src/lisp.h	Wed Nov 27 07:15:36 2002 +0000
@@ -2843,6 +2843,18 @@
 /*			   Checking for QUIT				*/
 /************************************************************************/
 
+/* NOTE NOTE NOTE: Invoking QUIT can cause random Lisp code to be executed!
+   This can happen in numerous ways.  For example, on many platforms, QUIT
+   needs to drain the event queue to see whether there's a C-g in the works.
+   A side effect of this is that, if there's a menu-press event, menu filters
+   (i.e. Lisp code) will be invoked.  Lisp code could also happen if there's
+   an asynchronous timeout, or if the debugger is invoked as a result of
+   debug-on-quit and the user returns by hitting `r', etc. etc.
+
+   However, GC CANNOT HAPPEN.  It is forbidden everywhere within the QUIT-
+   processing code, because most callers cannot tolerate GC during QUIT
+   since it's just too prevalent. */
+
 /* The exact workings of this mechanism are described in detail in signal.c. */
 
 /* Asynchronous events set something_happened, and then are processed
@@ -2897,8 +2909,9 @@
    However, this mechanism is inherently approximate, so it really
    doesn't matter much.) In the future, it might also include doing a
    thread context switch.  Callers of QUITP generally don't except
-   random side effects to happen, so we have this different
-   version. */
+   random side effects to happen (#### unfortunately, random side effects
+   can happen anyway, e.g. through menu filters -- see comment above),
+   so we have this different version. */
 #define INTERNAL_QUITP						\
   ((something_happened ? check_what_happened () : (void) 0),	\
    QUIT_FLAG_SAYS_SHOULD_QUIT)
@@ -3005,6 +3018,16 @@
    NNGCPROn().  If you need to nest yet another level, create
    the appropriate macros. */
 
+/* NOTE: About comments like "This function does not GC": These are there to
+   try to track whether GCPROing is necessary.  Strictly speaking, some
+   functions that say this might actually GC, but only when it is never
+   possible to return (more specifically, in the process of signalling an
+   error, the debugger may be invoked, and could GC).  For GCPRO purposes,
+   you only have to worry about functions that can GC and then return.
+   The QUIT macro cannot GC any more, although this wasn't true at some point,
+   and so some "This function can GC" comments may be inaccurate.
+*/
+
 #ifdef DEBUG_GCPRO
 
 void debug_gcpro1 (char *, int, struct gcpro *, Lisp_Object *);
@@ -3684,6 +3707,7 @@
 /* Defined in emacs.c */
 EXFUN (Fkill_emacs, 1);
 EXFUN (Frunning_temacs_p, 0);
+EXFUN (Fforce_debugging_signal, 1);
 
 SIGTYPE fatal_error_signal (int);
 Lisp_Object make_arg_list (int, Extbyte **);