2008/10/14 Rob Landley <[EMAIL PROTECTED]>: > On Tuesday 14 October 2008 05:18:44 Denys Vlasenko wrote: >> 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. > > I did a comment in the checkin, but a comment in the source makes sense too. > >> Did you try something smaller than 300ms? > > You could probably go below 300ms (I was pondering 250ms or even 100ms), but > there's no perfect minimum value. It's not that anybody's going to use this > code with a 300 bps modem, but on a loaded system where a scheduler delay > gets inserted in between receiving the escape and receiving the "[", deleting > to end of line is a bad failure mode to encounter. (Especially since you > don't always _notice_ that cursoring past something ate part of your file.) > > Since the blocking gets destroyed on a serial connection, the delay is what > strings the escape sequence characters back together, and asking "how long > might this code be interrupted by other activity on the system" has no good > answer, especially on slow systems. It _could_ be interrupted for a full > second if the executable page gets discarded due to memory constraints, and > has to be faulted back in from slow storage. > > Also, note that this delay is just until the system acts on the escape > character without another character pressed. If you type esc-colon-w-q > really fast, it'll act on it immediately, because that's not a recognized > escape sequence and it falls back to interpreting them as individual > characters as soon as it _knows_ this isn't an escape sequence. It knows > when the timeout occurs, and it knows when the pattern can't be an escape > sequence it knows about. > > Alas, the above is a bit long to put in a comment in the source code. :) >
You could check the latency of a typical busy system with this tool: http://www.latencytop.org/ it should give you some information about variance and then you could existamate the timeout as a fixed line speed timeout (i.e.: 25 ms for 1200bps) and N x variances, where N is choosed accordingly on the ratio damage/confidence of the event (i.e.: variance 10ms --> 25 + 8x10 = 105 ms should good enought for everybody. However I think that for a qemu and/or a real busy system 20/25 ms is a better extimation of the variance). Ciao, -- /roberto _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
