Lisp object allocations during asynchronous input handling

Lisp object allocations during asynchronous input handling

[YAMAMOTO Mitsuharu]

Forgive me if this issue has already been discussed.

A comment in src/termhooks.h says:

  /* Additional event argument.  This is used for TOOL_BAR_EVENTs and
     HELP_EVENTs and avoids calling Fcons during signal handling.  */
  Lisp_Object arg;

According to this, allocating Lisp objects during asynchronous input
handling seems to be evil.  Actually they operate on global variables
and thus not reentrant.  (Correct me if I'm wrong.)

However, drag-and-drop handling functions on any window systems (e.g.,
x_handle_dnd_message in xselect.c) are doing this kind of allocations
in order to cope with multiple dnd items.  And I can find other such
places in the Carbon port.  Actually, I made some of them without
noticing this issue.

So, my question is: should we make an effort to eliminate such parts
now?  I'm not sure how much they cause real problems.  And if
SYNC_INPUT will be defined in future, we won't need to worry about
such kind of allocations.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Lisp object allocations during asynchronous input handling

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 28 Nov 2005 11:34:32 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> However, drag-and-drop handling functions on any window systems
> (e.g., x_handle_dnd_message in xselect.c) are doing this kind of
> allocations in order to cope with multiple dnd items.  And I can
> find other such places in the Carbon port.  Actually, I made some of
> them without noticing this issue.

I've made some changes to avoid some of such allocations in the Carbon
port.  What's remaining is the drag-and-drop handling part as in other
platforms.

Is there any reason to set the cons of a frame and dnd items to the
`frame_or_window' member rather than setting them to `frame_or_window'
and `arg' separately?  Of course, this is not the only cause of Lisp
object allocations during asynchronous input handling, so separating
them as in the following patch is just a first step.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.844
diff -c -r1.844 keyboard.c
*** src/keyboard.c	10 Dec 2005 01:49:24 -0000	1.844
--- src/keyboard.c	11 Dec 2005 01:14:20 -0000
***************
*** 5805,5818 ****
  	Lisp_Object head, position;
  	Lisp_Object files;
  
! 	/* The frame_or_window field should be a cons of the frame in
! 	   which the event occurred and a list of the filenames
! 	   dropped.  */
! 	if (! CONSP (event->frame_or_window))
! 	  abort ();
! 
! 	f = XFRAME (XCAR (event->frame_or_window));
! 	files = XCDR (event->frame_or_window);
  
  	/* Ignore mouse events that were made on frames that
  	   have been deleted.  */
--- 5805,5812 ----
  	Lisp_Object head, position;
  	Lisp_Object files;
  
! 	f = XFRAME (event->frame_or_window);
! 	files = event->arg;
  
  	/* Ignore mouse events that were made on frames that
  	   have been deleted.  */
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.146
diff -c -r1.146 macterm.c
*** src/macterm.c	10 Dec 2005 01:49:53 -0000	1.146
--- src/macterm.c	11 Dec 2005 01:14:20 -0000
***************
*** 9191,9198 ****
        XSETINT (event.x, mouse.h);
        XSETINT (event.y, mouse.v);
        XSETFRAME (frame, f);
!       event.frame_or_window = Fcons (frame, file_list);
!       event.arg = Qnil;
        /* Post to the interrupt queue */
        kbd_buffer_store_event (&event);
        /* MAC_TODO: Mimic behavior of windows by switching contexts to Emacs */
--- 9756,9763 ----
        XSETINT (event.x, mouse.h);
        XSETINT (event.y, mouse.v);
        XSETFRAME (frame, f);
!       event.frame_or_window = frame;
!       event.arg = file_list;
        /* Post to the interrupt queue */
        kbd_buffer_store_event (&event);
        /* MAC_TODO: Mimic behavior of windows by switching contexts to Emacs */
Index: src/w32term.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32term.c,v
retrieving revision 1.236
diff -c -r1.236 w32term.c
*** src/w32term.c	14 Oct 2005 08:09:33 -0000	1.236
--- src/w32term.c	11 Dec 2005 01:14:21 -0000
***************
*** 3187,3194 ****
    DragFinish (hdrop);
  
    XSETFRAME (frame, f);
!   result->frame_or_window = Fcons (frame, files);
!   result->arg = Qnil;
    return Qnil;
  }
  
--- 3187,3194 ----
    DragFinish (hdrop);
  
    XSETFRAME (frame, f);
!   result->frame_or_window = frame;
!   result->arg = files;
    return Qnil;
  }
  
Index: src/xselect.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xselect.c,v
retrieving revision 1.155
diff -c -r1.155 xselect.c
*** src/xselect.c	7 Aug 2005 12:33:19 -0000	1.155
--- src/xselect.c	11 Dec 2005 01:14:22 -0000
***************
*** 2727,2737 ****
  
    mouse_position_for_drop (f, &x, &y);
    bufp->kind = DRAG_N_DROP_EVENT;
!   bufp->frame_or_window = Fcons (frame, vec);
    bufp->timestamp = CurrentTime;
    bufp->x = make_number (x);
    bufp->y = make_number (y);
!   bufp->arg = Qnil;
    bufp->modifiers = 0;
  
    return 1;
--- 2727,2737 ----
  
    mouse_position_for_drop (f, &x, &y);
    bufp->kind = DRAG_N_DROP_EVENT;
!   bufp->frame_or_window = frame;
    bufp->timestamp = CurrentTime;
    bufp->x = make_number (x);
    bufp->y = make_number (y);
!   bufp->arg = vec;
    bufp->modifiers = 0;
  
    return 1;

Re: Lisp object allocations during asynchronous input handling

[Richard M. Stallman]

It seems like an improvement to put the file args of the drag-n-drop
event into the `arg' field.  I wonder why that was not done before.