Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Feb 2013 14:02:08 +0200, Pavlo Martynenko <address@hidden> 
>>>>> said:

> "emacsclient -c" works fine when server was started from normally
> running emacs by (server-start).

> But when the server was started with --daemon option. The first time
> when emacsclient connects emacs eats 100% of cpu in main thread. And
> after client disconnects and connects again the server crashes on
> EXC_BAD_ACCESS in check_x_display_info.

> "emacsclient -t" terminates just after connect with exit code 1.

The Mac port is supposed to provide TTY-only sessions if invoked with
the --deamon option.  I'll look into this problem later so as to avoid
the crash at least.

> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
> frame minimised in the Dock. The same can not be said about the NS
> port.

This is a serious problem and specific to the Mac port.  Please try
the following patch and send a report to me (not to the list) if you
find some problem with this patch.

                                     YAMAMOTO Mitsuharu
                                address@hidden

=== modified file 'src/mac.c'
*** src/mac.c   2013-01-11 07:33:09 +0000
--- src/mac.c   2013-02-16 03:41:22 +0000
***************
*** 3117,3122 ****
--- 3117,3131 ----
    return event;
  }
  
+ static bool
+ mac_has_non_cgs_events_p (void)
+ {
+   ItemCount count = GetNumEventsInQueue (GetCurrentEventQueue ());
+ 
+   return (count > 1
+         || (count == 1 && GetEventClass (mac_peek_next_event ()) != 'cgs '));
+ }
+ 
  #if !SELECT_USE_GCD
  static struct
  {
***************
*** 3272,3283 ****
             mac_run_loop_run_once again so as to avoid wasting CPU
             time caused by vacuous reactivation of delayed visible
             toolbar item validation via window update events issued
!            in the application event loop.  */
          do
            {
              timeoutval = mac_run_loop_run_once (timeoutval);
            }
!         while (timeoutval && !mac_peek_next_event ()
                 && !detect_input_pending ());
          if (timeoutval == 0)
            timedout_p = 1;
--- 3281,3297 ----
             mac_run_loop_run_once again so as to avoid wasting CPU
             time caused by vacuous reactivation of delayed visible
             toolbar item validation via window update events issued
!            in the application event loop.
! 
!            Also, on Mac OS X 10.5 or later, the application receives
!            an event 'cgs '/15 if there is a miniaturized window.  We
!            don't want to break the loop in this case for a similar
!            reason.  */
          do
            {
              timeoutval = mac_run_loop_run_once (timeoutval);
            }
!         while (timeoutval && !mac_has_non_cgs_events_p ()
                 && !detect_input_pending ());
          if (timeoutval == 0)
            timedout_p = 1;
***************
*** 3394,3400 ****
          timeoutval = mac_run_loop_run_once (timeoutval);
        }
        while (timeoutval && !wokeup_from_run_loop_run_once_p
!            && !mac_peek_next_event () && !detect_input_pending ());
        if (timeoutval == 0)
        timedout_p = 1;
  
--- 3408,3414 ----
          timeoutval = mac_run_loop_run_once (timeoutval);
        }
        while (timeoutval && !wokeup_from_run_loop_run_once_p
!            && !mac_has_non_cgs_events_p () && !detect_input_pending ());
        if (timeoutval == 0)
        timedout_p = 1;
  
***************
*** 3416,3422 ****
          timeoutval = mac_run_loop_run_once (timeoutval);
        }
        while (timeoutval && !wokeup_from_run_loop_run_once_p
!            && !mac_peek_next_event () && !detect_input_pending ());
        if (timeoutval == 0)
        timedout_p = 1;
  
--- 3430,3436 ----
          timeoutval = mac_run_loop_run_once (timeoutval);
        }
        while (timeoutval && !wokeup_from_run_loop_run_once_p
!            && !mac_has_non_cgs_events_p () && !detect_input_pending ());
        if (timeoutval == 0)
        timedout_p = 1;