From xemacs-m  Tue Dec 17 12:49:23 1996
Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id MAA00478 for <xemacs-beta@xemacs.org>; Tue, 17 Dec 1996 12:49:22 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.3/8.6.9) with SMTP id KAA26786 for <xemacs-beta@xemacs.org>; Tue, 17 Dec 1996 10:49:24 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id KAA04109; Tue, 17 Dec 1996 10:47:40 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: sit-for bug & patch
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
From: David Moore <dmoore@UCSD.EDU>
Date: 17 Dec 1996 10:47:39 -0800
Message-ID: <rvhgllnh2s.fsf@sdnp5.ucsd.edu>
Lines: 73
X-Mailer: Red Gnus v0.75/XEmacs 19.15


	This is an intial patch, I will send a more comprehensive
solution later today, but this should amke life simpler for people
hitting 'C-l' every 10 seconds out of habit.

	Basically the problem is that if a timed handler calls (sit-for
0) itself, everything can wedge.

	Sit-for installs a timeout event of 0 duration and then
proceeeds to process any other timeout events that might have arrived
(such as display-time).  Display-time calls sit-for itself doing the
same thing.  The event queue now has the timeout event for the original
sit-for in front of the new timeout event.  The second recursive sit-for
essentially discards the original's timeout and waits for it's own.
Once it get's it's own, it returns.  And the original sit-for waits
around for an event that will never come.

	Current solution is to make nested sit-for's return immediately,
in that they can only be being caused by timed events, and the outermost
sit-for will do the same work that they were trying to do.  This is ok,
but it needs a better solution in the case of sleep-for.  If a timed
handler calls sleep-for, we need a way of letting xemacs sleep w/o the
original sit-for event being lost.  I'm going to work on this, but I
thought I'd let people know what the problem is and give an initial
patch which solves the common case.  It also looks like the more generic
solution I'm leaning towards might improve some timing numbers on the
benchmarks. :)


*** event-stream.c.orig	Tue Dec 17 10:18:59 1996
--- event-stream.c	Tue Dec 17 10:23:42 1996
***************
*** 2524,2529 ****
--- 2524,2531 ----
    return Qnil;
  }
  
+ static int already_in_sit_for = 0;
+ 
  DEFUN ("sit-for", Fsit_for, Ssit_for, 1, 2, 0 /*
  Perform redisplay, then wait ARG seconds or until user input is available.
  ARG may be a float, meaning a fractional part of a second.
***************
*** 2562,2573 ****
--- 2564,2581 ----
    if (noninteractive || !NILP (Vexecuting_macro))
      return (Qnil);
  
+   /* If we are called from a timeout handler, recursively invoked from
+      a previous sit-for, just return. */
+   if (already_in_sit_for)
+     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.
     */
    event = Fmake_event ();
    GCPRO1 (event);
+   already_in_sit_for++;
  
    /* Generate the wakeup even if MSECS is 0, so that existing timeout/etc.
       events get processed.  The old (pre-19.12) code special-cased this
***************
*** 2653,2658 ****
--- 2661,2667 ----
    else
      Fdeallocate_event (event);
  
+   already_in_sit_for--;
    UNGCPRO;
    return (result);
  }

