From xemacs-m  Wed Jan 22 10:35:26 1997
Received: from portofix.ida.liu.se (portofix.ida.liu.se [130.236.177.25])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id KAA08548 for <xemacs-beta@xemacs.org>; Wed, 22 Jan 1997 10:35:25 -0600 (CST)
Received: from sen2.ida.liu.se (sen2.ida.liu.se [130.236.176.112]) by portofix.ida.liu.se (8.8.3/8.8.3) with SMTP id RAA08315 for <xemacs-beta@xemacs.org>; Wed, 22 Jan 1997 17:35:24 +0100 (MET)
Received: by sen2.ida.liu.se (SMI-8.6/ida.slave-V1.0b6d6S2)
	id RAA00914; Wed, 22 Jan 1997 17:35:24 +0100
Date: Wed, 22 Jan 1997 17:35:24 +0100
Message-Id: <199701221635.RAA00914@sen2.ida.liu.se>
From: David Byers <davby@ida.liu.se>
To: xemacs-beta@xemacs.org
Subject: Sort of a bug in Fsit-for and Fsleep-for
X-Face: (@~#v$c[GP"T}a;|MU<%Dpm5*6yv"NR|7k;uk8MAISFxdZ(Og$C{u(j"9X7v$qonp}SKfhT
 g|5[Pu~/3F7XQEk70gK'4z%1R%%gg7]}=>/jD`qcBeHDgo&HS,^S!&.zoTSxh<>-O6EB?SSy96&m37

I recently reported a bug on xemacs@xemacs.org regarding sit-for,
filter functions and network streams. Unable to keep my mind focused
on what I should be doing, I figured out exactly what was going on.
I'm even pretty confident I got it right this time.

When a large amount of data arrives on the network at once, it is
split into several process events. The first of these is picked off
the event queue and handled by execute_internal_event. This causes the
filter function associated with the process to be invoked. This filter
function then calls sit-for. In Fsit_for there is a loop that checks
the event queue repeatedly for timeout events and eval events. Of
course, this loop picks off the next process event from the event
queue and hands it to execute_internal_event, which in turn causes the
filter function to be invoked.

This goes on until no more data is available on the network, at which
time the lisp stack is unwound. Of course, this means that the last
invocation of the filter function is executed first, and the first
invocation is executed last.

All this means that calling sit-for in a filter function (or in
anything *called* by a filter function) may be a very bad idea. The
same goes for sleep-for. 

In the example code I gave in my first report, the result was that
data was entered into a buffer in reverse order. In a package I am
working on, the result was a mass of errors when the filter function
tried to parse data in reverse order.

(Am I making sense so far?)

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
let Fsit_for and Fsleep_for re-enqueue process events, the same way
they do with eval events. I think the current behavior is dangerous.


I'd like to hear what others think: should sit-for and sleep-for
terminate when they see a process event? Should I write the code? Is
the current behavior preferable?

--
David Byers.


