On Thursday 16 October 2008 08:38:41 am 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 tend to agree with your previous mail, not this one :) If you got an ESC, next char is delayed by 8ms by serial line and you are scheduled away in poll(), there is no guarantee you come back 25ms and not 25s later. Kernel simply gives no such promises. In-kernel stuff (IRQs from gigabit ethernet which is flooded with UDP packets) also can delay processing of next character from serial line. It's actually quite easy to artificially create such conditions for testing. With enough of IRQs coming in, you can even make serial line lose characters. :) > 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. Couldn't resist, joined bikeshed painting :| and bumped it to 50. It's 5 scheduling intervals on a 100 Hz system, I consider system which does not deprive vi from scheduling for 5 timer tick intervals as a "system not yet too overloaded". 25ms is only 2 intervals. I also increased a count in read(). There is a non-obvious reason why bumping it past 3 would require more surgery, or "hold down Page Down" starts editing the file on it's own :) (hint: assigning "n = 0;" is wrong in this case). Testing: ./busybox vi busybox_unstripped.map <vi.cmd with arbitrary vi commands in vi.cmd > Checked in, with expanded comment explaining the problem, not the person who > found it. Thanks! -- vda _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
