From xemacs-m  Wed Mar 12 00:00:58 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA04268
	for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 00:00:56 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcgmy07372; Wed, 12 Mar 1997 01:00:50 -0500 (EST)
Date: Wed, 12 Mar 1997 01:00:50 -0500 (EST)
Message-Id: <QQcgmy07372.199703120600@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: 20.1-b6: sit-for and accept-process-output
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

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.

