From xemacs-m  Wed Mar 12 14:30:54 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 OAA13379
	for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 14:30:52 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcgpe22959; Wed, 12 Mar 1997 15:30:46 -0500 (EST)
Date: Wed, 12 Mar 1997 15:30:46 -0500 (EST)
Message-Id: <QQcgpe22959.199703122030@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: Re: 20.1-b6: sit-for and accept-process-output
In-Reply-To: <rvsp21t4bp.fsf@sdnp5.ucsd.edu>
References: <QQcgmy07372.199703120600@crystal.WonderWorks.COM>
	<rvsp21t4bp.fsf@sdnp5.ucsd.edu>
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

David Moore writes:
 > 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.

I managed to catch one of these spins in the debugger.
accept-process-output is being called and it is checking
recsursive_sit_for, finding it to be non-nil and is returning
immediately.  VM's POP code calls accept-process-output with a
non-nil second arg, so this immediate return is bogus behavior
according to the documentation for accept-process-output.

 > 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).

C-g is not treated the same as SIGINT in all cases.  See Fnext_event.
Sometimes it is read as a normal key and acted upon via a keymap.  If
this happens when a spin begins, the C-g's are buffered until the
loop is broken.  Sending a SIGINT kicks XEmacs out of the loop and
then you'll see repeated Quit messages for all the bufferd C-g's
(Which itself is interesting since I thought a C_g instigated quit
discarded buffered command input.  Perhaps not in the case of C-g's
treated as ordinary keystrokes.)

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

I'll try it.

