Re: possible data corruption while scrolling through rows

Mike Richardson wrote:
> On Monday 17 January 2005 15:47, abel deuring wrote:

>>Of course, a decent program must handle user input and other events as
>>quickly as possible, and some actions like database queries can take a
>>long time, hence it makes sense to call qApp->processEvents from time to
>>time. OTOH, making them reentrant safe can be quite complex, so I am
>>wondering, if of how is it possible to check, if certain events can be
>>executed immediately, or if it should queued for later execution. While
>>my patch does just that, but only "locally", based on a symptom; but I
>>think it is possible that other parts of Rekall might have similar
>>reentrance problems, so it would perhaps be better to check for possible
>>reentrance problems at a more centralized location.
> 
> 
> My first thoughts are, what we are interested in is not QT events themselves - 
> since that includes stuff like repaints - but "rekall" events, which would be 

Yeah -- this shows that I did not dive very deep into Rekall's source 
code ;)

> stuff like keystrokes and button clicks. Keystokes either update values in 
> controls, which should not be a problem unless the change triggers a "rekall" 
> event, in which case they are in the same class as, say a button click.
> 
> In that case there are two cases. Keystrokes get fed through the KBNavigator 
> class, so could probably be serialised there (ie., if KBNavigator gets a 
> keystroke while it is processing a previous one, then it is queues); events 
> like button clicks end up in an instance KBEvent (for the event they are 
> triggering) which again gives a serialisation point. Actually, I guess that 
> the two streams should be merged, probably at the form level. I hate this 
> sort of stuff, its a real PITA to test (and to reproduce any problems !)

As I understand it, a KBNavigator instance manages keystrokes for one 
block or container etc. Queueing events on this level may lead to some 
surprising results, I think. For example, assume a form with a block and 
a sub block. Let the user hit the down arrow key for the main block, 
then for the sub block, two times for the main block and again two times 
for the sub block. Moreover, assume that all these events except for the 
first one occur before the first call of qApp->processEvents from 
somewhere within the code that processes the first event. Admittedly, 
not very likely, but not impossible.

Event queueing on KBNavigator level will have two problems with this 
scenario, I think.

1. the execution of the of the first keystroke event for the subblock 
may lead to the same or a similar problem as I described in my first 
mail: the KBNavigator instance of the sub block can call 
KBFormBlock::doOperation at a time, where the same method is being 
called by KBFormBlock::doOperation of the parent block.

2. Even if the above problem is somehow avoided, the execution sequence 
of the five queued events may be changed. The two events for the main 
block are queued in the KBNavigator instance of the parent block, and 
the three events for the subblock in the its KBNavigator instance. At 
least, with the naive queueing model of my patch, this will cause the 
second keystroke event of the parent block being executed _before_ all 
events of the subblock, and all three events of the subblock will be 
executed last, which is not what the user will expect.

Hence I think it is better to have a centralized queue for Rekall 
events, i.e., all KBNavigator events and all KBEvents could/should be 
stuffed into the same queue. But keep in mind that I didn't read 
Rekall's sources in detail -- I know that I can easily write complete 
nonsense or propose things that are unnecessarily complex...

cheers
Abel