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. :) Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
