From xemacs-m  Thu Jan 23 13:37:40 1997
Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id NAA16917 for <xemacs-beta@xemacs.org>; Thu, 23 Jan 1997 13:37:37 -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 LAA18052 for <xemacs-beta@xemacs.org>; Thu, 23 Jan 1997 11:37:36 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA00262; Thu, 23 Jan 1997 11:35:09 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: Sort of a bug in Fsit-for and Fsleep-for
References: <199701221635.RAA00914@sen2.ida.liu.se> 	<kigohego1eh.fsf@jagor.srce.hr> <QQbztk06098.199701231702@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
Mail-Copies-To: never
From: David Moore <dmoore@UCSD.EDU>
Date: 23 Jan 1997 11:35:08 -0800
In-Reply-To: "Worry F. Wart"'s message of Thu, 23 Jan 1997 12:02:51 -0500 (EST)
Message-ID: <rv3evsjic3.fsf@sdnp5.ucsd.edu>
Lines: 44
X-Mailer: Red Gnus v0.80/XEmacs 19.15

"Worry F. Wart" <kyle_jones@wonderworks.com> writes:

>  > > I would prefer to see Fsit_for and Fsleep_for terminate when they see
>  > > a process event, but I don't know if anything obscure would break if
>  > > they did. Another possibility (that I don't beleive in) would be to
>  > 
>  > It doesn't look dangerous for Fsit_for and Fsleep_for to
>  > terminate on a process event.  Why don't you make the change,
>  > and see what happens to your XEmacs environment?  I think a
>  > breakage in that area would be pretty obvious.
> 
> Be careful.  The documented behavior of sit-for is to sleep until
> the time expires or _user_ input is available.  It is late in the
> beta cycle to be changing the semantics of a Lisp function like
> this.  The bug needs to be fixed, but we should avoid changing
> semantics if possible.


	I noticed the potential for this bad recursive behaviour when I
fixed the previous sit-for bug (that fix didn't change these
semantics).  I was going to try to solve this problem, but it's not
totally clean, and I hoped it wasn't biting anyone.

	You've got to be careful about using sit-for, sleep-for or
accept-process-output from a filter or timer that's already running
inside one of those.

	Life would be easier if you prevented people from doing things
such as (sleep-for 100) inside a filter.  But it's currently allowed,
and causes havok.

	I'd also like it to be the case that an error caused by a timer
event or filter doesn't kill the routine which did a sit-for, not
knowing that some errant timer was going to blow up.  This is easier to
fix, but I didn't at the time, since it changed the behaviour.  Maybe
someone wants an error in a timer to kill the routine which did a
sit-for. :)


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

