2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>: > On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote: >> On Sunday 12 October 2008 23:48:22 Rob Landley wrote: >> > Next time it reads a buffer, it starts with the last character of a cursor >> > left sequence: capital D. Capital D is "delete to end of line", which it >> > does. >> > >> > So basically, busybox vi is corrupting your data when you cursor around in >> > a file on a loaded system. Wheee... >> >> Hmmm... I redid the readit() code to only read ahead when processing an >> escape sequence. (This let me shrink the readahead buffer to 8 bytes, >> actually 5 but with 32 bit alignment 8 makes more sense. Bloatcheck says I >> shrunk the code by 17 bytes.) > > Disregard my previous patch, I just looked at your code and it's > as good but it's smaller than mine, so let's use yours. > >> Unfortunately, this mitigated the problem a bit, but didn't actually _fix_ >> it. >> It happens less often, but I can still trigger it. >> >> I _think_ this is actually a qemu issue. The escape sequences are being >> generated by the host Linux, which are then sent to the qemu process over a >> virtual serial console, which breaks them down into individual bytes with an >> interrupt for each. >> >> This means that the blocking we're depending on to parse escape sequences >> doesn't work over a serial console. You _can get an escape character by >> itself with poll saying there's no more data, and then on the next clock >> cycle you can get a "[D". >> >> Hmmm... >> >> Ok, making poll wait 300 miliseconds before deciding there's no next >> character >> in a pending escape sequence seems to have fixed it. (At least I can't >> reproduce the problem under qemu anymore.) > > Please document this next time, or someone else might come later > and delete the timeout. I did this a few mins ago :( will fix it now. > > Did you try something smaller than 300ms?
As far as I understood the problem: considering a 1200bps line, 120 chars per second, 40 escape sequence per seconds, then the minimum timeout should be at least 1/40 sec = 25 ms. This is for a fixed speed line, considering an asynchronous data line with an average speed of 1200bps and a bell curve variance of 25 ms then using a timeout of 100ms would catch the 0.999936657516% of the escape sequences. Enlarging the timeout to 150ms 0.999999998027%. Over 200ms should not make any sense any more if the variance has been correctly estimated in 25 ms. http://en.wikipedia.org/wiki/Normal_distribution Cheers, -- /roberto _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
