Asynchronous events in Carbon or Cocoa Emacs (macosx)

Asynchronous events in Carbon or Cocoa Emacs (macosx)

[Lloyd Zusman]

I'm not sure whether the following question is appropriate in this forum.
I've posted it in a few other emacs-related mailing lists and newsgroups,
but no one has responded. I figure that you developers might understand
this issue best, and you might be able to quickly answer my question.
Please forgive me if I have misjudged and should have not posted this here.

Under macosx (Leopard), I can run the latest builds of Carbon Emacs 
(22.3.1) or Cocoa Emacs (23.0.60) inside of a Terminal window by invoking
the following command lines from within Terminal:

    /path/to/Contents/MacOS/Emacs -nw FILE

... where FILE is the item that I want to edit.

If I run it in this way, events handled via Emacs' `special-event-map'
are invoked asynchronously and in real time ... or at least in near-real
time (they're processed the next time that Emacs becomes idle). For example,
if I define a [sigusr1] event, its `special-event-map' handler gets invoked
the next moment that Emacs goes idle after I send a USR1 signal to its
process. This is the behavior that I am expecting.

However, if I run Carbon or Cocoa Emacs without the `-nw' flag so that it 
creates and manages its own window outside of Terminal, these
`special-event-map' events don't get invoked in near-real time any more, but
rather, they only get processed the next time I interact directly with the
Emacs window with either the mouse or a keystroke.

In other words, if I am trapping [sigusr1] as described above and send a
USR1 signal to the process, nothing happens until after I click in the Emacs 
window with the mouse or perform some sort of keyboard interaction with it,
at which time the [sigusr1] events that have accumulated all get processed,
one after the other.

It's as if the windowed version of Carbon and Cocoa Emacs can only process
`special-event-map' events in synchronization with the keyboard and mouse
input queues. Or perhaps the explanation is that these versions of Emacs
don't consider themselves to be in an idle state except immediately after
they've finished processing keyboard and mouse events. Or maybe there's
a different explanation for this; I'm not an Emacs developer, so I'm only 
guessing.

Has anyone else seen this behavior? If so, is there any way that you know
of to tell the windowed version of Carbon/Cocoa Emacs to process [sigusr1]
and other `special-event-map' events asynchronously from the keyboard and
mouse, in the same way that they get processed when Emacs is started in
a Terminal window with the `-nw' option?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.

Re: Asynchronous events in Carbon or Cocoa Emacs (macosx)

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 10 Oct 2008 23:51:22 +0000 (UTC), Lloyd Zusman <ljz@asfast.com> said:

> However, if I run Carbon or Cocoa Emacs without the `-nw' flag so
> that it creates and manages its own window outside of Terminal,
> these `special-event-map' events don't get invoked in near-real time
> any more, but rather, they only get processed the next time I
> interact directly with the Emacs window with either the mouse or a
> keystroke.

> In other words, if I am trapping [sigusr1] as described above and
> send a USR1 signal to the process, nothing happens until after I
> click in the Emacs window with the mouse or perform some sort of
> keyboard interaction with it, at which time the [sigusr1] events
> that have accumulated all get processed, one after the other.

I'm not sure about the Cocoa/GNUstep port, but I can say something
about Carbon Emacs 22.

That's a known limitation in the `select' emulation of the Carbon
port, and I mentioned that when I updated the platform-independent
part of user-signal handling code to the current form:

  http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg00443.html

I have some experimental code to remedy this limitation, but it's not
tested that much.

				     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.899.2.11
diff -c -p -r1.899.2.11 keyboard.c
*** src/keyboard.c	25 Feb 2008 16:04:54 -0000	1.899.2.11
--- src/keyboard.c	11 Oct 2008 02:48:28 -0000
*************** struct user_signal_info
*** 7087,7092 ****
--- 7087,7094 ----
  /* List of user signals. */
  static struct user_signal_info *user_signals = NULL;
  
+ void (*handle_user_signal_hook) P_ ((int));
+ 
  void
  add_user_signal (sig, name)
       int sig;
*************** handle_user_signal (sig)
*** 7128,7133 ****
--- 7130,7137 ----
      if (p->sig == sig)
        {
  	p->npending++;
+ 	if (handle_user_signal_hook)
+ 	  (*handle_user_signal_hook) (sig);
  #ifdef SIGIO
  	if (interrupt_input)
  	  kill (getpid (), SIGIO);
Index: src/keyboard.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.h,v
retrieving revision 1.75.2.4
diff -c -p -r1.75.2.4 keyboard.h
*** src/keyboard.h	8 Jan 2008 04:30:01 -0000	1.75.2.4
--- src/keyboard.h	11 Oct 2008 02:48:28 -0000
*************** extern Lisp_Object Qscroll_bar_movement;
*** 297,302 ****
--- 297,304 ----
  /* Symbols to use for non-text mouse positions.  */
  extern Lisp_Object Qmode_line, Qvertical_line, Qheader_line;
  
+ extern void (*handle_user_signal_hook) P_ ((int));
+ 
  /* Forward declaration for prototypes.  */
  struct input_event;
  
Index: src/mac.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/Attic/mac.c,v
retrieving revision 1.77.2.10
diff -c -p -r1.77.2.10 mac.c
*** src/mac.c	29 Aug 2008 08:18:07 -0000	1.77.2.10
--- src/mac.c	11 Oct 2008 02:48:28 -0000
*************** static CFMutableDictionaryRef cfsockets_
*** 4958,4963 ****
--- 4958,5018 ----
  /* Process ID of Emacs.  */
  static pid_t mac_emacs_pid;
  
+ static int wakeup_fds[2];
+ 
+ static void
+ wakeup_callback (s, type, address, data, info)
+      CFSocketRef s;
+      CFSocketCallBackType type;
+      CFDataRef address;
+      const void *data;
+      void *info;
+ {
+   char buf[64];
+ 
+   while (emacs_read (CFSocketGetNative (s), buf, sizeof (buf)) > 0)
+     ;
+ }
+ 
+ int
+ init_wakeup_fds ()
+ {
+   int result, i;
+   int flags;
+   CFSocketRef socket;
+   CFRunLoopSourceRef source;
+ 
+   result = pipe (wakeup_fds);
+   if (result < 0)
+     return result;
+   for (i = 0; i < 2; i++)
+     {
+       flags = fcntl (wakeup_fds[i], F_GETFL, 0);
+       result = fcntl (wakeup_fds[i], F_SETFL, flags | O_NONBLOCK);
+       if (result < 0)
+ 	return result;
+     }
+   socket = CFSocketCreateWithNative (NULL, wakeup_fds[0],
+ 				     kCFSocketReadCallBack,
+ 				     wakeup_callback, NULL);
+   if (socket == NULL)
+     return -1;
+   source = CFSocketCreateRunLoopSource (NULL, socket, 0);
+   CFRelease (socket);
+   if (source == NULL)
+     return -1;
+   CFRunLoopAddSource ((CFRunLoopRef)
+ 		      GetCFRunLoopFromEventLoop (GetCurrentEventLoop ()),
+ 		      source, kCFRunLoopDefaultMode);
+   CFRelease (source);
+   return 0;
+ }
+ 
+ void mac_wakeup_from_run_loop_run_once ()
+ {
+   emacs_write (wakeup_fds[1], "", 1);
+ }
+ 
  static void
  socket_callback (s, type, address, data, info)
       CFSocketRef s;
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/Attic/macterm.c,v
retrieving revision 1.214.2.31
diff -c -p -r1.214.2.31 macterm.c
*** src/macterm.c	2 Sep 2008 08:19:06 -0000	1.214.2.31
--- src/macterm.c	11 Oct 2008 02:48:28 -0000
*************** x_delete_display (dpyinfo)
*** 9436,9441 ****
--- 9436,9452 ----
  }
  
  \f
+ #ifdef MAC_OSX
+ void
+ mac_handle_user_signal (sig)
+      int sig;
+ {
+   extern void mac_wakeup_from_run_loop_run_once P_ ((void));
+ 
+   mac_wakeup_from_run_loop_run_once ();
+ }
+ #endif	/* MAC_OSX */
+ 
  /* Set up use of X before we make the first connection.  */
  
  extern frame_parm_handler mac_frame_parm_handlers[];
*************** mac_initialize ()
*** 9522,9527 ****
--- 9533,9543 ----
  
  #if TARGET_API_MAC_CARBON
  #ifdef MAC_OSX
+   if (init_wakeup_fds () < 0)
+     abort ();
+ 
+   handle_user_signal_hook = mac_handle_user_signal;
+ 
    init_coercion_handler ();
  
    init_dm_notification_handler ();

Re: Asynchronous events in Carbon or Cocoa Emacs (macosx)

[Lloyd Zusman]

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

> >>>>> On Fri, 10 Oct 2008 23:51:22 +0000 (UTC), Lloyd Zusman <ljz <at>
asfast.com> said:
> 
> > [ ... ]
> >
> > In other words, if I am trapping [sigusr1] as described above and
> > send a USR1 signal to the process, nothing happens until after I
> > click in the Emacs window with the mouse or perform some sort of
> > keyboard interaction with it, at which time the [sigusr1] events
> > that have accumulated all get processed, one after the other.
> 
> [ ... ]
> 
> That's a known limitation in the `select' emulation of the Carbon
> port, and I mentioned that when I updated the platform-independent
> part of user-signal handling code to the current form:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg00443.html
> 
> I have some experimental code to remedy this limitation, but it's not
> tested that much.
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp
> 
> [ ... etc. ... ]

Thank you very much.

I do remember reading that post, but I confess that at the time, I
didn't understand the significance of it regarding the issue that I
reported here.

I'll get a hold of the Carbon Emacs source code and play with this
patch. Once I have some results, I'll post them here.


-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.