From xemacs-m  Wed Mar 12 11:18:23 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id LAA11612
	for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 11:18:20 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id JAA29769 for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 09:18:20 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id JAA28146; Wed, 12 Mar 1997 09:20:27 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: 20.1-b6: sit-for and accept-process-output
References: <QQcgmy07372.199703120600@crystal.WonderWorks.COM>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Mar_12_09:20:26_1997-1"
Content-Transfer-Encoding: 7bit
From: David Moore <dmoore@ucsd.edu>
Date: 12 Mar 1997 09:20:26 -0800
In-Reply-To: Kyle Jones's message of Wed, 12 Mar 1997 01:00:50 -0500 (EST)
Message-ID: <rvsp21t4bp.fsf@sdnp5.ucsd.edu>
Lines: 168
X-Mailer: Gnus v5.4.17/XEmacs 19.15

--Multipart_Wed_Mar_12_09:20:26_1997-1
Content-Type: text/plain; charset=US-ASCII

Kyle Jones <kyle_jones@wonderworks.com> writes:

> I have a feeling something is rotten between sit-for and
> accept-process-output.  I have seen XEmacs go into a spin
> several times now, where I know sit-for was called around
> the same time that VM's POP client went looking for mail.
> C-g will break out of it sometimes, but sometimes it won't.
> Senidng a SIGINT will break the loop in those cases.  This
> isn't new to b6.  Only recently have I become convinced that it
> isn't filladapt looping or some timer code bug, which I had been
> suspecting since I've been hacking on all that stuff.

There are some new changes to accept-process-output in 19.15b99 and
20.1b7.  On the other hand I'm not sure this is what you're seeing.
Since there shouldn't be a difference between C-g and SIGINT unless
something elsewhere is getting confused (like Xt or how we are checking
for C-g using SIGIO).

It also looks like we have some memory corruption and garbage collection
problems.  yay.

Here is the patch for accept-process-output for b99 and b7, if you want
to try it.


--Multipart_Wed_Mar_12_09:20:26_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="ev.diff"
Content-Transfer-Encoding: 7bit

--- event-stream.c.orig	Sat Mar  8 22:20:06 1997
+++ event-stream.c	Sat Mar  8 22:43:07 1997
@@ -2357,9 +2357,8 @@
 /* This is used in accept-process-output, sleep-for and sit-for.
    Before running any process_events in these routines, we set
    recursive_sit_for to Qt, and use this unwind protect to reset it to
-   Qnil upon exit.  When recursive_sit_for is Qt, calling any of these
-   three routines will cause them to return immediately no matter what
-   their arguments were. 
+   Qnil upon exit.  When recursive_sit_for is Qt, calling sit-for will
+   cause it to return immediately.
    
    All of these routines install timeouts, so we clear the installed
    timeout as well.
@@ -2395,13 +2394,6 @@
 If the third arg is non-nil, it is a number of milliseconds that is added
  to the second arg.  (This exists only for compatibility.)
 Return non-nil iff we received any output before the timeout expired.
-
-If a filter function or timeout handler (such as installed by `add-timeout')
- calls any of accept-process-output, sleep-for, or sit-for, those calls
- will return nil immediately (regardless of their arguments) in recursive
- situations.  It is recommended that you never call accept-process-output
- from inside of a process filter function or timer event (either synchronous
- or asynchronous).
 */
        (process, timeout_secs, timeout_msecs))
 {
@@ -2415,10 +2407,6 @@
   struct buffer *old_buffer = current_buffer;
   int count;
 
-  /* Recusive call from a filter function or timeout handler. */
-  if (!NILP(recursive_sit_for))
-    return Qnil;
-
   /* We preserve the current buffer but nothing else.  If a focus
      change alters the selected window then the top level event loop
      will eventually alter current_buffer to match.  In the mean time
@@ -2536,12 +2524,8 @@
 Pause, without updating display, for ARG seconds.
 ARG may be a float, meaning pause for some fractional part of a second.
 
-If a filter function or timeout handler (such as installed by `add-timeout')
- calls any of accept-process-output, sleep-for, or sit-for, those calls
- will return nil immediately (regardless of their arguments) in recursive
- situations.  It is recommended that you never call sleep-for from inside
- of a process filter function or timer event (either synchronous or
- asynchronous).
+It is recommended that you never call sleep-for from inside of a process
+ filter function or timer event (either synchronous or asynchronous).
 */
        (seconds))
 {
@@ -2552,10 +2536,6 @@
   int count;
   struct gcpro gcpro1;
 
-  /* Recusive call from a filter function or timeout handler. */
-  if (!NILP(recursive_sit_for))
-    return Qnil;
-
   GCPRO1 (event);
 
   id = event_stream_generate_wakeup (msecs, 0, Qnil, Qnil, 0);
@@ -2616,12 +2596,8 @@
  happen if input is available before it starts.
 Value is t if waited the full time with no input arriving.
 
-If a filter function or timeout handler (such as installed by `add-timeout')
- calls any of accept-process-output, sleep-for, or sit-for, those calls
- will return nil immediately (regardless of their arguments) in recursive
- situations.  It is recommended that you never call sit-for from inside
- of a process filter function or timer event (either synchronous or
- asynchronous) with an argument other than 0.
+If sit-for is called from within a process filter function or timer
+ event (either synchronous or asynchronous) it will return immediately.
 */
        (seconds, nodisplay))
 {
@@ -2632,10 +2608,6 @@
   int id;
   int count;
 
-  /* Recusive call from a filter function or timeout handler. */
-  if (!NILP(recursive_sit_for))
-    return Qnil;
-
   /* The unread-command-events count as pending input */
   if (!NILP (Vunread_command_events) || !NILP (Vunread_command_event))
     return Qnil;
@@ -2657,6 +2629,18 @@
   if (noninteractive || !NILP (Vexecuting_macro))
     return (Qnil);
 
+  /* Recusive call from a filter function or timeout handler. */
+  if (!NILP(recursive_sit_for))
+    {
+      if (!event_stream_event_pending_p (1) && NILP (nodisplay))
+	{
+	  run_pre_idle_hook ();
+	  redisplay ();
+	}
+      return Qnil;
+    }
+
+
   /* Otherwise, start reading events from the event_stream.
      Do this loop at least once even if (sit-for 0) so that we
      redisplay when no input pending.
@@ -4619,10 +4603,7 @@
       (/ (- (caddr ,end) (caddr ,start)) 1000000.0)))
 
 (defun testee (ignore)
-  ;; All three of these should return immediately.
-  (sit-for 10)
-  (sleep-for 10)
-  (accept-process-output nil 10))
+  (sit-for 10))
 
 (defun test-them ()
   (let ((start (current-time))
@@ -4636,7 +4617,8 @@
     (setq end (current-time))
     (test-diff-time start end)))
 
-(test-them) should sit for 15 seconds, not 105 or 96.
-
+(test-them) should sit for 15 seconds.
+Repeat with testee set to sleep-for and accept-process-output.
+These should each delay 36 seconds.
 
 */

--Multipart_Wed_Mar_12_09:20:26_1997-1--

