Re: C-g does not interrupt lisp code (emacs 21)

[Philippe Waroquiers]

> > sigblock(0x2000) ......................................... = 8192
> 
>   (1)
> Hmhmhm, the code is a maze in this area...
> 
> I think this has something to do with polling for input.  In both 20
> and 21, a SIGALRM handler should be used for polling, i.e. looking for
> input while Emacs is doing something else (that's the alarm(2)/sigvec
> I guess in the trace of 20).  In 21, the SIGALRM, which should call
> function poll_for_input, might have been blocked in (1), but I can't
> see where that is in the code.  Is there a way to get more information
> out of the trace?  Could you please add a printf to poll_for_input
> to verify that it is really not running?

poll_for_input is not called. After searching more in details, the problem
is in atimer.c. A call to UNBLOCK_ATIMERS gives (after pre-processing)
an empty line. 
adding 
hey sigunblock (8192);
hey BLOCK_ATIMERS;
hey UNBLOCK_ATIMERS;

gives:

hey  ;
hey sigblock ((1L << (14-1))) ;
hey  ;

(after pre-processing -P atimer.c).
C-g works with the following piece of code:
  /* Insert the timer in the list of active atimers.  */
  schedule_atimer (t);
  printf ("bef unblock_atimers %d\n ", sigblock (0));
  UNBLOCK_ATIMERS;
  printf ("after unblock_atimers %d\n ", sigblock (0));
  sigsetmask (sigblock (0) & ~ 8192);
  printf ("after local unblock %d\n ", sigblock (0));

It is not clear to me how to see in syssignal.h this sigunblock definition 
should
come from.
If I can do something more, do not hesitate ....



MORE DETAILS (probably not needed to read them if above summary is clear) 
-------------------------------------------------------------------------

Looking more in details where sigblock was called, I obtained the following 
stack
trace (nb: this is already a modified atimer.c, see below):

          Breakpoint 3, 0x7efb1cc0 in sigblock () from /usr/lib/libc.2
          (gdb) bt
          #0  0x7efb1cc0 in sigblock () from /usr/lib/libc.2
          #1  0x2251cc in start_atimer (type=ATIMER_RELATIVE, time={tv_sec = 1, 
tv_usec = 0}, fn=0x400d3eea <show_hourglass>, client_data=0x0)
              at atimer.c:132
          #2  0x108b8c in start_hourglass () at xfns.c:10351
          #3  0x11f358 in command_loop_1 () at keyboard.c:1638
          #4  0x1c2224 in internal_condition_case (bfun=0x400d40da 
<command_loop_1>, handlers=269707460, hfun=0x400d40e2 <cmd_error>)
              at eval.c:1267
          #5  0x11d9ac in command_loop_2 () at keyboard.c:1245
          #6  0x1c1b50 in internal_catch (tag=269659812, func=0x400d40ca 
<command_loop_2>, arg=269585412) at eval.c:1030
          #7  0x11d938 in command_loop () at keyboard.c:1224
          #8  0x11d0fc in recursive_edit_1 () at keyboard.c:950
          #9  0x11d300 in Frecursive_edit () at keyboard.c:1006
          #10 0x11b54c in main (argc=3, argv=0x7eff45a4, envp=0x7eff45b4) at 
emacs.c:1547
          (gdb)


I tried then to step into the UNBLOCK_ATIMERS line in atimer.c (just before the
set_alarm in function start_atimer.
This line was ignored by gdb (as it is a comment).
I then modified the code to add tracing and I saw that the signal was still
blocked after the unblock_atimers.
So, it seems that one way or another, the UNBLOCK_ATIMERS results in no code.

The following code shows it :
  /* Insert the timer in the list of active atimers.  */
  schedule_atimer (t);
  printf ("bef unblock_atimers %d\n ", sigblock (0));
  UNBLOCK_ATIMERS;
  printf ("after unblock_atimers %d\n ", sigblock (0));
  sigsetmask (sigblock (0) & ~ 8192);
  printf ("after local unblock %d\n ", sigblock (0));

gives the following trace:
gull: ./emacs
bef unblock_atimers 8192
 after unblock_atimers 8192
 after local unblock 0
 bef unblock_atimers 8192
 after unblock_atimers 8192
 after local unblock 0
 bef unblock_atimers 8192
 after unblock_atimers 8192
 after local unblock 0
 bef unblock_atimers 8192
 after unblock_atimers 8192
 after local unblock 0
 bef unblock_atimers 8192
 after unblock_atimers 8192
 after local unblock 0

With the above change, the C-g is interrupting the (while t).

Here is the cc command launched by make emacs:
        cc -c -Wp,-H200000 -D_BSD    -I/tmp/emacs_home/emacs-21.1/xpm-3.4k 
-Demacs -DHAVE_CONFIG_H -DUSE_LUCID  -I. -I/tmp/emacs_home/emacs-21.1/src   
-Wp,-H200000 -D_BSD    -I/usr/include/X11R6    -I/usr/include/X11R6 
-I/usr/include/X11R5 -I/usr/include/Motif1.2 -I/usr/contrib/X11R6/include 
-I/usr/contrib/X11R5/include  -g atimer.c

When adding -P to the cc commands, in the similar code area, I obtain:
  schedule_atimer (t);
  printf ("bef unblock_atimers %d\n ", sigblock (0));
   ;
  printf ("after unblock_atimers %d\n ", sigblock (0));
  sigsetmask (sigblock (0) & ~ 8192);
  printf ("after local unblock %d\n ", sigblock (0));

So, the pre-processing supposed to give an unblock fails.
This is the sigunblock which gives empty because a direct insertion of

hey sigunblock (8192);
hey BLOCK_ATIMERS;
hey UNBLOCK_ATIMERS;

gives:

hey  ;
hey sigblock ((1L << (14-1))) ;
hey  ;

-- 
Philippe WAROQUIERS                  Eurocontrol - Central Flow Management Unit
philippe.waroquiers@eurocontrol.int  Rue de la fusee, 96
Tel: +32 2 729 97 35                 1130 Brussels
Fax: +32 2 729 90 22                 Belgium