bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jim Radford <radford@blackbean.org>]

On Wed, Oct 15, 2014 at 07:50:52PM +0200, Jan Djärv wrote:
> 13 okt 2014 kl. 09:13 skrev Jim Radford <radford@blackbean.org>:
> 
> > I often cannot connect to "emacs --daemon" with emacsclient because
> > instead of select()ing on the appropriate sockets it's stuck in [NSApp
> > run] waiting for an event which will never come.  Note at this time
> > there are no Cocoa windows open (I don't use them) so no events will
> > *ever* come (unless I, say, open and close the about box which triggers
> > an escape from the hang).  Here's the backtrace when this occurs.
> > 
> >    frame #9: 0x00007fff940cc89b AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> >    frame #10: 0x00000001001a659f Emacs`-[EmacsApp run](self=0x0000000100a26910, _cmd=<unavailable>) + 223 at nsterm.m:4494
> >    frame #11: 0x00000001001a5219 Emacs`ns_select(nfds=<unavailable>, readfds=0x00007fff5fbfea00, writefds=0x00007fff5fbfe980, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) + 809 at nsterm.m:3748
> > 
> Cocoa does not allow you to disconnect and connect the GUI like X can.
> So running a Cocoa compiled Emacs as --daemon does not make much sense.
> You are seeing the consequence of this.

What doesn't make sense is running two main loops in the same thread
and trying to alternatively spin on one (EmacsApp run) and then the
other (select) without knowing which might produce the next event.
That is guaranteed to fail, as I am seeing.

I'm going to guess that you can't register file descriptors with the
Cocoa main loop nor get a file descriptor from it that you can pass to
select?  Could we instead spawn a thread just to run select() in a
loop, passing the results to the main thread as a Cocoa event?  Or
visa versa?

-Jim