bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Eli Zaretskii]

> From:     Didier Verna <didier@didierverna.net>
> Cc: 13103@debbugs.gnu.org
> Date: Thu, 06 Dec 2012 22:24:11 +0100
> 
>   Here's the result of gdb's 'where' when I kill -TSTP the Emacs.app
>   process, after attaching GDB to it. Not sure that's very useful. Also,
>   I should point out that Emacs itself does NOT hang or become
>   unresponsive. It works like a charm. It's just that the CPU usage goes
>   way up.
> 
> 
> 
> #0  0x00007fff838dfd7a in mach_msg_trap ()
> #1  0x00007fff838e0444 in mach_msg ()
> #2  0x00007fff89580902 in __CFRunLoopRun ()
> #3  0x00007fff8957fd8f in CFRunLoopRunSpecific ()
> #4  0x00007fff809507ee in RunCurrentEventLoopInMode ()
> #5  0x00007fff809505f3 in ReceiveNextEventCommon ()
> #6  0x00007fff809504ac in BlockUntilNextEventMatchingListInMode ()
> #7  0x00007fff83ae4eb2 in _DPSNextEvent ()
> #8  0x00007fff83ae4801 in -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #9  0x00007fff83aaa68f in -[NSApplication run] ()
> #10 0x0000000100191d95 in ns_select (nfds=1, readfds=0x7fff5fbfa290, 
> writefds=0x7fff5fbfa210, exceptfds=<value temporarily unavailable, due to 
> optimizations>, timeout=0x7fff5fbfa330, sigmask=<value temporarily 
> unavailable, due to optimizations>) at 
> /usr/local/src/emacs/trunk/src/nsterm.m:3537
> #11 0x000000010015dfad in wait_reading_process_output
> #(time_limit=<value temporarily unavailable, due to optimizations>,
> #nsecs=0, read_kbd                  

Next step is to see which file descriptor is being watched here.
(There's only one because nfds = 1.)

Also, I suggest to do this experiment several times, to make sure that
this is indeed related to the call to ns_select.