GNU bug report logs - #21313
25.0.50; Strange errors from dbus-handle-event

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 21313 <at> debbugs.gnu.org
Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Fri, 16 Oct 2015 11:23:19 +0300

> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: michael.albinus <at> gmx.de,  21313 <at> debbugs.gnu.org
> Date: Fri, 16 Oct 2015 09:45:08 +0200
> 
> Ok, so QUIT; in C code basically means, here is a position where the
> current lisp execution could be aborted.  If it weren't in
> print_object(), then you couldn't for example abort printing a list with
> gazillions of elements and emacs would get stuck while doing so.

Correct.

> Looking at QUIT, the difference between my original code and the new one
> is just when process_quit_flag() is called.  process_quit_flag() always
> signals quit.  So with the new code, the signal is handled by the right
> recipient.  Who consumed (and discarded) it before?

process_quit_flag itself:

  void
  process_quit_flag (void)
  {
    Lisp_Object flag = Vquit_flag;
    Vquit_flag = Qnil; <<<<<<<<<<<<<<<<<<<<<<<

The gotcha here is that C-g is handled specially, i.e. not by
process_quit_flag, during processing of user input.  That special
handling was bypassed because process_quit_flag attempted to process
it too early, and reseted the flag afterwards, thus disabling that
special processing.

> Well, I think I just remember that I want to bind Qinhibit_quit to Qt
> whenever I need to call Lisp functions from C.

In debugging code that isn't supposed to disrupt the control flow,
yes, that's a good rule.  But if you write C code for "normal"
processing, then no, don't inhibit quitting like that just because you
call Lisp.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.