2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>: > 2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>: >> 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 >> > > Because the distribution for delays follows a poisson curve you > should add 25ms to the timeout I previously estimated: 100 -> 125, 150 > -> 175 and 200 -> 225. This because the after having wait for 25 ms > (fixed speed line) the poisson curve could be fairly approximated with > a gaussian curve. >
Pressing ESC each second the mean time of a text corruption event would be: 25+125 = 150 ms --> 2 days 25+150 = 175 ms --> 16 years I think 200 ms would be sufficient to cover the everybody expectation life time. Ciao, -- /roberto _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
