On Tue, Jun 24, 2003 at 03:26:04PM +0200, Asger Kunuk Alstrup wrote: > On Tue, 24 Jun 2003, Andre Poenitz wrote: > > > But in addition to the purely cosmetic issues of 'noupdate 2', there are > > now lots of (unfixable) hard crashs. The reason is mainly the current > > cursor implementation. The stored row iterators get invalidated pretty > > fast -> boom. > > > > Comments, ideas? > > One way forward would be to implement "stable" iterators as discussed > earlier. The row iterators are issued from a special kind of list which > will remember all issued iterators, and make sure they are always up to > date when the list changes. I.e. the cursor iterators will always be > valid in the sense that they do not crash when dereferenced.
In the full-rebreak-everytime approach there is only one operation modifying the row list: its creation. I wonder whether we could get something cheaper than the stable iterators. Simple integer offset from begin or similar... Another (and certainly robust) option would be a 'marker': Put a special marker (inset?) at cursor position on begin of rebreak, drop the row cache, start rebreaking line by line, re-set the cursor once the marker is hit. I am a bit wary of highly interconnected data structure although I see that in case of stable iterators there might be a possibility to encapsulate the dependencies nicely... OTOH, stable iterators might indeed be much cheaper than I think and more flexible in the long run. Since we are at it: Assume we had stable iterators the way you've proposed. How does one copy these things? Wouldn't that mean that the copy has to register itself with the list? I.e. we'd need a copy constructor with side effects? > A simple way to do this is to just change all the issued iterators to the > first element in the list when the list changes. That should be enough to > prevent crashes, although the cursor would jump rather aggressively to the > top when the flow is redone. From here, you can go two ways: 1) Fix all > list operations to make more intelligent adjustments to all issued > iterators. 2) Eliminator all usages of these iterators. As a help, you can > extend the list implementation with debug-spew to help you. > > This way, you can make a local change which will prevent the crashes, > but introduce other problems, but you will still be afloat. Then, one by > one, you can change the list iterators, cursor scheme, or the other > things, and thus address the various problems one-by-one using the salami > method: Address the most important, managable problem at each step, and > after N steps, you might have succeeded. The 'problem' is that even such 'break only small things' changes are currently not accepted. > I think the crucial thing is that you can debug and reasonable > complete each step: The program should be in so good shape that you are > able to test that each refactoring is complete and working before you > proceed to the next step. I.e. in other words, do not leave 200 TODOs in > the process, because those will be very hard/next to impossible to fix > later. You can not make such a big transformation in the blind, so you > have to keep the program working enough to verify each change. If your point is working _enough_ I fully agree. But I don't see a point in requiring 'zero tolerance' concerning regressions as long as the list of regression is small (like 'only cosmetical issues in rare circumstances' etc). Of course, finding consensus on where to draw the line is not simple... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
