bug#5723: 23.1.94; make-network-process and emacs hangs

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

The source code of make-network-process (around line 3648 in process.c)
seems to suggest that this function is blocking and my experience can
confirm the case.

When there's no network connection, make-network-process returns in a
short duration. Where it become nasty is in a network where certain
ports are blocked, for example, in my uni's wireless network, the irc
port is blocked and if I accidentally run M-x irc then emacs hangs for
hours.

Could this be improved i.e. by wrapping it in with-local-quit?

Thanks.


In GNU Emacs 23.1.94.1 (x86_64-apple-darwin10.2.0, Carbon Version 1.6.0 AppKit 1038.25)
 of 2010-03-14 on Victoria.local
Windowing system distributor `Apple Inc.', version 10.6.2
configured using `configure  '--prefix=/usr/local/unix/emacs' '--with-mac' 'CFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

bug#5723: 23.1.94; make-network-process and emacs hangs

[Dan Nicolaescu]

Leo <sdl.web@gmail.com> writes:

  > In GNU Emacs 23.1.94.1 (x86_64-apple-darwin10.2.0, Carbon Version 1.6.0 AppKit 1038.25)
                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  >  of 2010-03-14 on Victoria.local
  > Windowing system distributor `Apple Inc.', version 10.6.2
  > configured using `configure  '--prefix=/usr/local/unix/emacs' '--with-mac' 'CFLAGS=''
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why do you keep reporting bugs to this version here?
This is not the proper place to report bugs/ or even discuss that
version.
Are using M-x report-emacs-bug to do that?
If yes, you should request the people that support that version to send
the bugs to the appropriate address.

If what you report are generic bugs, then you should first reproduce
them on either one of our releases / pretest versions or the bzr tree,
and send a bug report for that version.

Thanks

bug#5723: 23.1.94; make-network-process and emacs hangs

[Stefan Monnier]

> Could this be improved i.e. by wrapping it in with-local-quit?

If it's called somewhere where C-g doesn't work, yes it's a bug.


        Stefan

bug#5723: 23.1.94; make-network-process and emacs hangs

[Helmut Eller]

* Stefan Monnier [2010-03-15 20:22+0100] writes:

>> Could this be improved i.e. by wrapping it in with-local-quit?
>
> If it's called somewhere where C-g doesn't work, yes it's a bug.

make-network-process calls getaddrinfo and C-g doesn't work properly
during that call.  It's only observable if the name server is slow or
misconfigured.

glibc has a asynchronous variant getaddrinfo_a (in libanl.so) which uses
threads internally and quickly passes control back to the caller.  That
could be used on GNU/Linux but the OP uses a Mac.

Helmut

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Mar 2010 23:49:25 +0100, Helmut Eller <eller.helmut@gmail.com> said:

> * Stefan Monnier [2010-03-15 20:22+0100] writes:
>>> Could this be improved i.e. by wrapping it in with-local-quit?
>> 
>> If it's called somewhere where C-g doesn't work, yes it's a bug.

> make-network-process calls getaddrinfo and C-g doesn't work properly
> during that call.  It's only observable if the name server is slow
> or misconfigured.

> glibc has a asynchronous variant getaddrinfo_a (in libanl.so) which
> uses threads internally and quickly passes control back to the
> caller.  That could be used on GNU/Linux but the OP uses a Mac.

I guess OP's case is about `connect' rather than `getaddrinfo'.

  http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00148.html

Leo, can you check where it blocks (using GDB), and whether giving
--without-sync-input as a configure option changes the situation
(using the X11 build, preferably)?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 2010-03-16 00:45 +0000, YAMAMOTO Mitsuharu wrote:
>> make-network-process calls getaddrinfo and C-g doesn't work properly
>> during that call.  It's only observable if the name server is slow
>> or misconfigured.
>
>> glibc has a asynchronous variant getaddrinfo_a (in libanl.so) which
>> uses threads internally and quickly passes control back to the
>> caller.  That could be used on GNU/Linux but the OP uses a Mac.
>
> I guess OP's case is about `connect' rather than `getaddrinfo'.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00148.html
>
> Leo, can you check where it blocks (using GDB), and whether giving
> --without-sync-input as a configure option changes the situation
> (using the X11 build, preferably)?

With this option and build emacs with X11, I can't start the gui
version, getting this error:

Xlib: unexpected async reply (sequence 0x5c)!

Starting emacs with emacs -nw I can quit with C-g nicely. 

I have no luck with --with-mac, C-g still can not stop the process.

Leo

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Mar 2010 12:01:16 +0000, Leo <sdl.web@gmail.com> said:

>> I guess OP's case is about `connect' rather than `getaddrinfo'.
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00148.html
>> 
>> Leo, can you check where it blocks (using GDB), and whether giving
>> --without-sync-input as a configure option changes the situation
>> (using the X11 build, preferably)?

> With this option and build emacs with X11, I can't start the gui
> version, getting this error:

> Xlib: unexpected async reply (sequence 0x5c)!

> Starting emacs with emacs -nw I can quit with C-g nicely.

> I have no luck with --with-mac, C-g still can not stop the process.

The Carbon port and its descendants use polling with SIGALRM to check
whether C-g is pressed.  The systems without SIGIO (such as Solaris 8)
work similarly even with X11.  If your case blocks at `connect', then
it can't be quit with C-g regardless of SYNC_INPUT on those
ports/systems, because atimer is turned off during the `connect' call.

      immediate_quit = 1;
      QUIT;

      /* This turns off all alarm-based interrupts; the
	 bind_polling_period call above doesn't always turn all the
	 short-interval ones off, especially if interrupt_input is
	 set.

	 It'd be nice to be able to control the connect timeout
	 though.  Would non-blocking connect calls be portable?

	 This used to be conditioned by HAVE_GETADDRINFO.  Why?  */

      turn_on_atimers (0);

      ret = connect (s, lres->ai_addr, lres->ai_addrlen);
      xerrno = errno;

      turn_on_atimers (1);

Again, could you check if it actually blocks at `connect', using GDB?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Helmut Eller]

* YAMAMOTO Mitsuharu [2010-03-18 02:57+0100] writes:

> If your case blocks at `connect', then
> it can't be quit with C-g regardless of SYNC_INPUT on those
> ports/systems, because atimer is turned off during the `connect' call.

Why is the timer turned off around connect?  Handling SIGALARM during
connect doesn't seem much different from handling SIGIO.

Helmut

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 18 Mar 2010 08:43:45 +0100, Helmut Eller <eller.helmut@gmail.com> said:

> * YAMAMOTO Mitsuharu [2010-03-18 02:57+0100] writes:
>> If your case blocks at `connect', then it can't be quit with C-g
>> regardless of SYNC_INPUT on those ports/systems, because atimer is
>> turned off during the `connect' call.

> Why is the timer turned off around connect?  Handling SIGALARM
> during connect doesn't seem much different from handling SIGIO.

I think your argument makes sense.

I don't know the reason why the timer is turned off around connect.
The related code was added by the following change:

  committer: Ken Raeburn <raeburn@raeburn.org>
  timestamp: Sat 2000-06-24 06:06:53 +0000
  message:
    * process.c (Fopen_network_stream): Turn off atimers for duration of call to
    connect.  (Patch from Gerd.)

  http://cvs.savannah.gnu.org/viewvc/emacs/src/process.c?root=emacs&r1=1.314&r2=1.315

And as of this change, SIGIO was also disabled.

25249 kwzh@gn |       /* Kernel bugs (on Ultrix at least) cause lossage (not just EINTR)
25249 kwzh@gn | 	 when connect is interrupted.  So let's not let it get interrupted.
25249 kwzh@gn | 	 Note we do not turn off polling, because polling is only used
25249 kwzh@gn | 	 when not interrupt_input, and thus not normally used on the systems
25249 kwzh@gn | 	 which have this bug.  On systems which use polling, there's no way
25249 kwzh@gn | 	 to quit if polling is turned off.  */
25249 kwzh@gn |       if (interrupt_input)
25249 kwzh@gn | 	unrequest_sigio ();
25249 kwzh@gn | 
25249 kwzh@gn |       immediate_quit = 1;
25249 kwzh@gn |       QUIT;
25249 kwzh@gn | 
29922 raeburn |       /* This turns off all alarm-based interrupts; the
29922 raeburn | 	 bind_polling_period call above doesn't always turn all the
29922 raeburn | 	 short-interval ones off, especially if interrupt_input is
29922 raeburn | 	 set.
29922 raeburn | 
29922 raeburn | 	 It'd be nice to be able to control the connect timeout
29922 raeburn | 	 though.  Would non-blocking connect calls be portable?  */
29922 raeburn |       turn_on_atimers (0);
25249 kwzh@gn |       ret = connect (s, lres->ai_addr, lres->ai_addrlen);
29922 raeburn |       turn_on_atimers (1);

Does anyone have the mailing list archive around 2000-06?  It's not
found at list.gnu.org.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 18 Mar 2010 18:06:20 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> If your case blocks at `connect', then it can't be quit with C-g
>>> regardless of SYNC_INPUT on those ports/systems, because atimer is
>>> turned off during the `connect' call.

>> Why is the timer turned off around connect?  Handling SIGALARM
>> during connect doesn't seem much different from handling SIGIO.

> I think your argument makes sense.

The current code closes the socket and call `connect' again if
(blocking) `connect' is interrupted by a signal.

2004-11-09  Kim F. Storm  <storm@cua.dk>

	* process.c (Fmake_network_process): Remove kludge for interrupted
	connects on BSD.  If connect is interrupted, just close socket and
	start over rather than sleeping and retry with same socket.

(http://cvs.savannah.gnu.org/viewvc/emacs/src/process.c?root=emacs&r1=1.443&r2=1.444)

UNIX Network Programming (Richard Stevens et al.) says "What we must
do in this scenario is call /select/" (Section 16,5, Volume 1 third
edition).

Also, POSIX says:

  If connect() is interrupted by a signal that is caught while blocked
  waiting to establish a connection, connect() shall fail and set
  errno to [EINTR], but the connection request shall not be aborted,
  and the connection shall be established asynchronously.

  ...

  When the connection has been established asynchronously, select()
  and poll() shall indicate that the file descriptor for the socket is
  ready for writing.

(http://www.opengroup.org/onlinepubs/000095399/functions/connect.html)

Perhaps we should try this, not just removing `turn_on_atimers' calls.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Helmut Eller]

* YAMAMOTO Mitsuharu [2010-03-19 02:47+0100] writes:

>>>>>> On Thu, 18 Mar 2010 18:06:20 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>
>>>> If your case blocks at `connect', then it can't be quit with C-g
>>>> regardless of SYNC_INPUT on those ports/systems, because atimer is
>>>> turned off during the `connect' call.
>
>>> Why is the timer turned off around connect?  Handling SIGALARM
>>> during connect doesn't seem much different from handling SIGIO.
>
>> I think your argument makes sense.
>
> The current code closes the socket and call `connect' again if
> (blocking) `connect' is interrupted by a signal.
>
> 2004-11-09  Kim F. Storm  <storm@cua.dk>
>
> 	* process.c (Fmake_network_process): Remove kludge for interrupted
> 	connects on BSD.  If connect is interrupted, just close socket and
> 	start over rather than sleeping and retry with same socket.
>
> (http://cvs.savannah.gnu.org/viewvc/emacs/src/process.c?root=emacs&r1=1.443&r2=1.444)
>
> UNIX Network Programming (Richard Stevens et al.) says "What we must
> do in this scenario is call /select/" (Section 16,5, Volume 1 third
> edition).
>
> Also, POSIX says:
>
>   If connect() is interrupted by a signal that is caught while blocked
>   waiting to establish a connection, connect() shall fail and set
>   errno to [EINTR], but the connection request shall not be aborted,
>   and the connection shall be established asynchronously.
>
>   ...
>
>   When the connection has been established asynchronously, select()
>   and poll() shall indicate that the file descriptor for the socket is
>   ready for writing.
>
> (http://www.opengroup.org/onlinepubs/000095399/functions/connect.html)
>
> Perhaps we should try this, not just removing `turn_on_atimers' calls.

I had reported that already in 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5173
but was silently ignored.

Helmut

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 19 Mar 2010 07:41:54 +0100, Helmut Eller <eller.helmut@gmail.com> said:

>> The current code closes the socket and call `connect' again if
>> (blocking) `connect' is interrupted by a signal.
>> 
>> 2004-11-09  Kim F. Storm  <storm@cua.dk>
>> 
>> * process.c (Fmake_network_process): Remove kludge for interrupted
>> connects on BSD.  If connect is interrupted, just close socket and
>> start over rather than sleeping and retry with same socket.
>> 
>> (http://cvs.savannah.gnu.org/viewvc/emacs/src/process.c?root=emacs&r1=1.443&r2=1.444)
>> 
>> UNIX Network Programming (Richard Stevens et al.) says "What we must
>> do in this scenario is call /select/" (Section 16,5, Volume 1 third
>> edition).
(snip)
>> Perhaps we should try this, not just removing `turn_on_atimers' calls.

> I had reported that already in 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5173
> but was silently ignored.

Oh, I didn't notice that.

I think the essential part of the suggested code, as well as the
removal of turn_on_atimers calls, should go to the trunk for further
testing on various platforms.  Maintainers, what do you think?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Stefan Monnier]

> I think the essential part of the suggested code, as well as the
> removal of turn_on_atimers calls, should go to the trunk for further
> testing on various platforms.  Maintainers, what do you think?

I'm not very knowledgeable when it comes to network coding, but it
sounds right.  It's at least worth a try.  Could I first see the
corresponding patch, tho?


        Stefan

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 19 Mar 2010 09:29:52 -0400, Stefan Monnier <monnier@IRO.UMontreal.CA> said:

>> I think the essential part of the suggested code, as well as the
>> removal of turn_on_atimers calls, should go to the trunk for
>> further testing on various platforms.  Maintainers, what do you
>> think?

> I'm not very knowledgeable when it comes to network coding, but it
> sounds right.  It's at least worth a try.  Could I first see the
> corresponding patch, tho?

Helmut's patch is available from
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5173 .

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 2010-03-19 10:21 +0000, YAMAMOTO Mitsuharu wrote:
> Oh, I didn't notice that.
>
> I think the essential part of the suggested code, as well as the
> removal of turn_on_atimers calls, should go to the trunk for further
> testing on various platforms.  Maintainers, what do you think?
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

I have applied the patch and removed turn_on_atimers calls. Everything
seems to work perfectly.

Leo

bug#5723: 23.1.94; make-network-process and emacs hangs

[Chong Yidong]

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

> I think the essential part of the suggested code, as well as the
> removal of turn_on_atimers calls, should go to the trunk for further
> testing on various platforms.  Maintainers, what do you think?

I have looked through the patch, and it looks plausible to me.  But I am
not an expert on networking.  I think you should go ahead and check it
into the trunk for testing.

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 24 Mar 2010 18:00:08 -0400, Chong Yidong <cyd@stupidchicken.com> said:

>> I think the essential part of the suggested code, as well as the
>> removal of turn_on_atimers calls, should go to the trunk for
>> further testing on various platforms.  Maintainers, what do you
>> think?

> I have looked through the patch, and it looks plausible to me.  But
> I am not an expert on networking.  I think you should go ahead and
> check it into the trunk for testing.

Could you take care of the copyright assignment process if necessary?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Chong Yidong]

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

>> I have looked through the patch, and it looks plausible to me.  But
>> I am not an expert on networking.  I think you should go ahead and
>> check it into the trunk for testing.
>
> Could you take care of the copyright assignment process if necessary?

Helmut Eller already has an assignment on file.

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 2010-03-18 01:57 +0000, YAMAMOTO Mitsuharu wrote:
> The Carbon port and its descendants use polling with SIGALRM to check
> whether C-g is pressed.  The systems without SIGIO (such as Solaris 8)
> work similarly even with X11.  If your case blocks at `connect', then
> it can't be quit with C-g regardless of SYNC_INPUT on those
> ports/systems, because atimer is turned off during the `connect' call.
>
>       immediate_quit = 1;
>       QUIT;
>
>       /* This turns off all alarm-based interrupts; the
> 	 bind_polling_period call above doesn't always turn all the
> 	 short-interval ones off, especially if interrupt_input is
> 	 set.
>
> 	 It'd be nice to be able to control the connect timeout
> 	 though.  Would non-blocking connect calls be portable?
>
> 	 This used to be conditioned by HAVE_GETADDRINFO.  Why?  */
>
>       turn_on_atimers (0);
>
>       ret = connect (s, lres->ai_addr, lres->ai_addrlen);
>       xerrno = errno;
>
>       turn_on_atimers (1);
>
> Again, could you check if it actually blocks at `connect', using GDB?

It looks like it. See:

#0  0x00007fff828c3f66 in connect ()
#1  0x000000010014d715 in Fmake_network_process ()
#2  0x0000000100106a17 in Ffuncall ()
#3  0x0000000100142407 in Fbyte_code ()
#4  0x00000001001062fc in funcall_lambda ()
#5  0x000000010010670f in Ffuncall ()
#6  0x0000000100142407 in Fbyte_code ()
#7  0x0000000100105d60 in Feval ()
#8  0x0000000100108841 in internal_lisp_condition_case ()
#9  0x0000000100141471 in Fbyte_code ()
#10 0x00000001001062fc in funcall_lambda ()
#11 0x000000010010670f in Ffuncall ()
#12 0x000000010010337f in Fcall_interactively ()
#13 0x0000000100106958 in Ffuncall ()
#14 0x0000000100106af6 in call3 ()
#15 0x00000001000935c0 in Fexecute_extended_command ()
#16 0x000000010010697e in Ffuncall ()
#17 0x000000010010337f in Fcall_interactively ()
#18 0x0000000100106958 in Ffuncall ()
#19 0x0000000100106af6 in call3 ()
#20 0x00000001000a125d in command_loop_1 ()
#21 0x0000000100104e27 in internal_condition_case ()
#22 0x00000001000985ee in command_loop_2 ()
#23 0x0000000100104f30 in internal_catch ()
#24 0x0000000100099018 in command_loop ()
#25 0x000000010009948f in recursive_edit_1 ()
#26 0x000000010009962b in Frecursive_edit ()
#27 0x000000010008eea7 in main ()

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Mar 2010 12:01:16 +0000, Leo <sdl.web@gmail.com> said:

>> I guess OP's case is about `connect' rather than `getaddrinfo'.
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00148.html
>> 
>> Leo, can you check where it blocks (using GDB), and whether giving
>> --without-sync-input as a configure option changes the situation
>> (using the X11 build, preferably)?

> With this option and build emacs with X11, I can't start the gui
> version, getting this error:

> Xlib: unexpected async reply (sequence 0x5c)!

I found a missing BLOCK_INPUT that may or may not be related to this:

=== modified file 'src/xfns.c'
*** src/xfns.c	2010-03-15 17:16:46 +0000
--- src/xfns.c	2010-03-18 02:14:30 +0000
***************
*** 3347,3353 ****
--- 3347,3355 ----
  #ifdef USE_LUCID
    /* Prevent lwlib/xlwmenu.c from crashing because of a bug
       whereby it fails to get any font.  */
+   BLOCK_INPUT;
    xlwmenu_default_font = XLoadQueryFont (FRAME_X_DISPLAY (f), "fixed");
+   UNBLOCK_INPUT;
  #endif
  
    /* Frame contents get displaced if an embedded X window has a border.  */

Could you try if C-g works for you case on X11 builds, both
--with-sync-input and --without-sync-input?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 2010-03-18 02:20 +0000, YAMAMOTO Mitsuharu wrote:
>> With this option and build emacs with X11, I can't start the gui
>> version, getting this error:
>
>> Xlib: unexpected async reply (sequence 0x5c)!
>
> I found a missing BLOCK_INPUT that may or may not be related to this:
>
> === modified file 'src/xfns.c'
> *** src/xfns.c	2010-03-15 17:16:46 +0000
> --- src/xfns.c	2010-03-18 02:14:30 +0000
> ***************
> *** 3347,3353 ****
> --- 3347,3355 ----
>   #ifdef USE_LUCID
>     /* Prevent lwlib/xlwmenu.c from crashing because of a bug
>        whereby it fails to get any font.  */
> +   BLOCK_INPUT;
>     xlwmenu_default_font = XLoadQueryFont (FRAME_X_DISPLAY (f), "fixed");
> +   UNBLOCK_INPUT;
>   #endif
>   
>     /* Frame contents get displaced if an embedded X window has a border.  */
>
> Could you try if C-g works for you case on X11 builds, both
> --with-sync-input and --without-sync-input?

Yes, I can now start emacs X11 and C-g can stop the hang for both
--with-sync-input and --without-sync-input.

It would great if something like this is available to mac-port ;)

Leo

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 18 Mar 2010 10:00:41 +0000, Leo <sdl.web@gmail.com> said:

>> Could you try if C-g works for you case on X11 builds, both
>> --with-sync-input and --without-sync-input?

> Yes, I can now start emacs X11 and C-g can stop the hang for both
> --with-sync-input and --without-sync-input.

> It would great if something like this is available to mac-port ;)

Perhaps we can try to see if removal of the `turn_on_atimers' calls
around `connect' can solve the problem without introducing any bad
effect.  If it works, then it will contribute not only to the Mac port
but also the NS port and non-SIGIO systems such as Solaris 8.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 18 March 2010 10:37, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Thu, 18 Mar 2010 10:00:41 +0000, Leo <sdl.web@gmail.com> said:
>
>>> Could you try if C-g works for you case on X11 builds, both
>>> --with-sync-input and --without-sync-input?
>
>> Yes, I can now start emacs X11 and C-g can stop the hang for both
>> --with-sync-input and --without-sync-input.
>
>> It would great if something like this is available to mac-port ;)
>
> Perhaps we can try to see if removal of the `turn_on_atimers' calls
> around `connect' can solve the problem without introducing any bad
> effect.  If it works, then it will contribute not only to the Mac port
> but also the NS port and non-SIGIO systems such as Solaris 8.
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp
>

I tried that and I can now quit with C-g although not as immediate as
in the X11 build.

Leo

bug#5723: 23.1.94; make-network-process and emacs hangs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 18 Mar 2010 10:47:22 +0000, Leo <sdl.web@googlemail.com> said:

>> Perhaps we can try to see if removal of the `turn_on_atimers' calls
>> around `connect' can solve the problem without introducing any bad
>> effect.  If it works, then it will contribute not only to the Mac
>> port but also the NS port and non-SIGIO systems such as Solaris 8.

> I tried that and I can now quit with C-g although not as immediate as
> in the X11 build.

Thanks for testing.  The delay was expected because the use of atimer
means periodic polling.  Unlike X11, window events for Carbon or Cocoa
don't come from socket, so we can't use SIGIO.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#5723: 23.1.94; make-network-process and emacs hangs

[Leo]

On 2010-03-15 19:22 +0000, Stefan Monnier wrote:
>> Could this be improved i.e. by wrapping it in with-local-quit?
>
> If it's called somewhere where C-g doesn't work, yes it's a bug.
>
>
>         Stefan

Sorry for the delay.

C-g does not work neither does with-local-quit. I think the problem
needs to be addressed somewhere else.

Leo

bug#5723: (no subject)

[YAMAMOTO Mitsuharu]

Closed with this change:

revno: 99751
committer: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
branch nick: trunk
timestamp: Thu 2010-03-25 17:56:15 +0900
message:
  Don't call turn_on_atimers around `connect' (Bug#5723).