Delivery-Date: 
Sender: info-hol-request@ted.cs.uidaho.edu
Errors-To: info-hol-request@ted.cs.uidaho.edu
Precedence: bulk
Original-Received: from localhost.inria.fr by 
                   margaux.inria.fr, Sat, 15 May 93 10:35:33 +0200
PP-warning: Illegal Received field on preceding line
To: Phil Windley <windley@panther.cs.uidaho.edu>
Cc: info-hol@ted.cs.uidaho.edu, murthy@margaux.inria.fr
Subject: Re: Emacs/HOL interface
In-Reply-To: Your message of Fri, 14 May 93 15:08:14 -0700. <199305142208.AA00702@panther.cs.uidaho.edu>
Return-Receipt-To: Chet.Murthy@inria.fr
Date: Sat, 15 May 93 10:35:31 N
Message-Id: <11702.737454931@margaux.inria.fr>
From: Chet.Murthy@inria.fr


The problem is two-fold.  First, Emacs will try to send too large a
region to HOL.  This is remedied by getting Emacs to send shorter
regions.  But also, most Emacs packages are written to send all the
text, and THEN and ONLY THEN look for the subshell's response.  So if
you send enough text, the subshell will send back lots of output, and
end up blocking, waiting to write to its output channel.  And you end
up blocking to write to the subshell.

Deadlock.

This happens less when the subshell is on another machine from your
Emacs, since then you get the Ethernet as a big buffer.  But the only
real solution is to put "accept-process-input" (or whatever) calls in
your output routines.

Second problem comes when you send too much text on a line.  Most
subshells are run within a PTY, with the PTY set to the "cooked" line
discipline.  Which means that it does input line buffering in the
kernel.  So you send a line of, say, 5000 characters.  And the input
line buffer gets full.  And the line discipline sends you back ... a
screenful of control-G's.  Pleasant.  The only solution for this is to
send shorter lines.  Cbreak mode on suns is only guaranteed to read
every 4 characters, so its a pain to use, and raw mode disables
control-key interrupt processing.

--chet--