You can't spell "evil" without "vi".

[Ralf Friedl]

I had the impression that original problem was when an ESC-sequence 
crossed the input buffer, not that it had something to do with the 
timeout after the ESC.
So is this whole discussion now about a different, but related problem?

Also, I don't understand the problem with poll potentially waiting 
longer that specified under heavy load. If poll really waits longer, it 
is more likely that additional data has arrived in this time, not less 
likely.

Regards
Ralf Friedl

Rob Landley wrote:
> On Wednesday 15 October 2008 11:36:19 Rob Landley wrote:
>   
>> I think I can work out a test for this (write a script suspending the qemu
>> process with "while true; do kill -STOP $PID; sleep 1; kill -CONT $PID;
>> sleep 1; done" and then hold down "cursor left" in vi for a couple minutes
>> and see if it zaps the line it's on.
>>     
>
> I finally got a chance to do this, and qemu did _not_ eat the line.  So the 
> serial interrupt takes precedence over the timer interrupt in Linux, which 
> means all we have to worry about is the actual serial delay.  I trimmed it 
> down to 25 miliseconds, which should be plenty for the next character to come 
> in at 1200 bps, and is way the heck below any human perceptual threshold.
>
> Checked in, with expanded comment explaining the problem, not the person who 
> found it.