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

[Roberto A. Foglietta]

2008/10/14 Roberto A. Foglietta <roberto.foglietta at gmail.com>:
> 2008/10/14 Roberto A. Foglietta <roberto.foglietta at gmail.com>:
>> 2008/10/14 Denys Vlasenko <vda.linux at googlemail.com>:
>>> 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