all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
@ 2014-10-13  7:13 Jim Radford
  2014-10-15 17:50 ` Jan Djärv
  0 siblings, 1 reply; 7+ messages in thread
From: Jim Radford @ 2014-10-13  7:13 UTC (permalink / raw)
  To: 18705

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
    frame #12: 0x0000000100179811 Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=true, wait_for_cell=4328534074, wait_proc=0x0000000000000000, just_wait_proc=<unavailable>) + 2209 at process.c:4601
    frame #13: 0x00000001000c1ce4 Emacs`read_decoded_event_from_main_queue [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) + 807 at keyboard.c:3906
    frame #14: 0x00000001000c19bd Emacs`read_decoded_event_from_main_queue [inlined] read_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>) + 1569 at keyboard.c:2246
    frame #15: 0x00000001000c139c Emacs`read_decoded_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>) + 44 at keyboard.c:2310
    frame #16: 0x00000001000c021e Emacs`read_char(commandflag=1, map=4322429222, prev_event=4328534074, used_mouse_menu=0x00007fff5fbff1ff, end_time=0x0000000000000000) + 5918 at keyboard.c:2895
    frame #17: 0x00000001000bc9d3 Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1859 at keyboard.c:9088
    frame #18: 0x00000001000bc064 Emacs`command_loop_1 + 5188 at keyboard.c:1452
    frame #19: 0x000000010013714b Emacs`internal_condition_case(bfun=0x00000001000bac20, handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1354
    frame #20: 0x00000001000cc4ae Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
    frame #21: 0x0000000100136ae3 Emacs`internal_catch(tag=<unavailable>, func=0x00000001000cc470, arg=4328534074) + 243 at eval.c:1118
    frame #22: 0x00000001000ba1ed Emacs`recursive_edit_1 [inlined] command_loop + 91 at keyboard.c:1156
    frame #23: 0x00000001000ba192 Emacs`recursive_edit_1 + 130 at keyboard.c:777
    frame #24: 0x00000001000ba39c Emacs`Frecursive_edit + 236 at keyboard.c:848
    frame #25: 0x00000001000b8fec Emacs`main(argc=0, argv=<unavailable>) + 5836 at emacs.c:1646
    frame #26: 0x00007fff928685fd libdyld.dylib`start + 1

In GNU Emacs 24.3.93.2 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
 of 2014-09-20
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --prefix=/tmp/emacs --with-ns'





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
  2014-10-13  7:13 bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo Jim Radford
@ 2014-10-15 17:50 ` Jan Djärv
  2014-10-15 18:52   ` Jim Radford
                     ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Jan Djärv @ 2014-10-15 17:50 UTC (permalink / raw)
  To: Jim Radford; +Cc: 18705

Hello.

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.

So basically, don't do this. :-)

	Jan D.

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
>    frame #12: 0x0000000100179811 Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=true, wait_for_cell=4328534074, wait_proc=0x0000000000000000, just_wait_proc=<unavailable>) + 2209 at process.c:4601
>    frame #13: 0x00000001000c1ce4 Emacs`read_decoded_event_from_main_queue [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) + 807 at keyboard.c:3906
>    frame #14: 0x00000001000c19bd Emacs`read_decoded_event_from_main_queue [inlined] read_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>) + 1569 at keyboard.c:2246
>    frame #15: 0x00000001000c139c Emacs`read_decoded_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>) + 44 at keyboard.c:2310
>    frame #16: 0x00000001000c021e Emacs`read_char(commandflag=1, map=4322429222, prev_event=4328534074, used_mouse_menu=0x00007fff5fbff1ff, end_time=0x0000000000000000) + 5918 at keyboard.c:2895
>    frame #17: 0x00000001000bc9d3 Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1859 at keyboard.c:9088
>    frame #18: 0x00000001000bc064 Emacs`command_loop_1 + 5188 at keyboard.c:1452
>    frame #19: 0x000000010013714b Emacs`internal_condition_case(bfun=0x00000001000bac20, handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1354
>    frame #20: 0x00000001000cc4ae Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
>    frame #21: 0x0000000100136ae3 Emacs`internal_catch(tag=<unavailable>, func=0x00000001000cc470, arg=4328534074) + 243 at eval.c:1118
>    frame #22: 0x00000001000ba1ed Emacs`recursive_edit_1 [inlined] command_loop + 91 at keyboard.c:1156
>    frame #23: 0x00000001000ba192 Emacs`recursive_edit_1 + 130 at keyboard.c:777
>    frame #24: 0x00000001000ba39c Emacs`Frecursive_edit + 236 at keyboard.c:848
>    frame #25: 0x00000001000b8fec Emacs`main(argc=0, argv=<unavailable>) + 5836 at emacs.c:1646
>    frame #26: 0x00007fff928685fd libdyld.dylib`start + 1
> 
> In GNU Emacs 24.3.93.2 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
> of 2014-09-20
> Windowing system distributor `Apple', version 10.3.1265
> Configured using:
> `configure --prefix=/tmp/emacs --with-ns'
> 
> 






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
  2014-10-15 17:50 ` Jan Djärv
@ 2014-10-15 18:52   ` Jim Radford
  2014-10-15 19:21   ` Stefan Monnier
       [not found]   ` <20141015185932.GA28148@home.blackbean.org>
  2 siblings, 0 replies; 7+ messages in thread
From: Jim Radford @ 2014-10-15 18:52 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 18705

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
  2014-10-15 17:50 ` Jan Djärv
  2014-10-15 18:52   ` Jim Radford
@ 2014-10-15 19:21   ` Stefan Monnier
  2014-10-16  5:44     ` Jan Djärv
  2015-05-17 15:38     ` Jan Djärv
       [not found]   ` <20141015185932.GA28148@home.blackbean.org>
  2 siblings, 2 replies; 7+ messages in thread
From: Stefan Monnier @ 2014-10-15 19:21 UTC (permalink / raw)
  To: Jan Djärv; +Cc: Jim Radford, 18705

> Cocoa does not allow you to disconnect and connect the GUI like X can.

Would it make sense to never disconnect (when in daemon), then?
Kind of like what we do for Gtk to try and circumvent the infamous problem,


        Stefan





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
       [not found]     ` <19878B19-176E-4345-A5F7-CC1E005C63B7@swipnet.se>
@ 2014-10-16  5:36       ` Jan Djärv
  0 siblings, 0 replies; 7+ messages in thread
From: Jan Djärv @ 2014-10-16  5:36 UTC (permalink / raw)
  To: Jim Radford; +Cc: 18705

Hi.

Don't remove the debbugs address.

15 okt 2014 kl. 20:59 skrev Jim Radford <radford@blackbean.org>:

> 
> 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.

Probably.  That is why we don't do that.

> 
> 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?

We do that.

	Jan D.







^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
  2014-10-15 19:21   ` Stefan Monnier
@ 2014-10-16  5:44     ` Jan Djärv
  2015-05-17 15:38     ` Jan Djärv
  1 sibling, 0 replies; 7+ messages in thread
From: Jan Djärv @ 2014-10-16  5:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Jim Radford, 18705

Hello.

15 okt 2014 kl. 21:21 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> Cocoa does not allow you to disconnect and connect the GUI like X can.
> 
> Would it make sense to never disconnect (when in daemon), then?
> Kind of like what we do for Gtk to try and circumvent the infamous problem,

The original report was short on details, so we don't know the commands he did w.r.t. GUI frames or -nw frames.  Its mixing those that can get you into trouble.
AFAIK, the NS port never disconnects.  If the NSApp run loop has been entered once, it will always be used.

	Jan D.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo
  2014-10-15 19:21   ` Stefan Monnier
  2014-10-16  5:44     ` Jan Djärv
@ 2015-05-17 15:38     ` Jan Djärv
  1 sibling, 0 replies; 7+ messages in thread
From: Jan Djärv @ 2015-05-17 15:38 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Jim Radford, 18705-done

Closing this bug as not reproducable.
Reopen if there is a reproducable test case.

	Jan D.






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-05-17 15:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-13  7:13 bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo Jim Radford
2014-10-15 17:50 ` Jan Djärv
2014-10-15 18:52   ` Jim Radford
2014-10-15 19:21   ` Stefan Monnier
2014-10-16  5:44     ` Jan Djärv
2015-05-17 15:38     ` Jan Djärv
     [not found]   ` <20141015185932.GA28148@home.blackbean.org>
     [not found]     ` <19878B19-176E-4345-A5F7-CC1E005C63B7@swipnet.se>
2014-10-16  5:36       ` Jan Djärv

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.