Re: possible data corruption while scrolling through rows

On Tuesday 18 January 2005 13:14, abel deuring wrote:
> 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...

I think the centralised queue is right. I thought of hooking into KBNavigator 
since all keystrokes go through there; we could feed from there into a common 
queue object.

I've realised that "rekall" events are more tricky, since by the time we have 
one, the "real" event (mouse click, for instance) has already passed through 
the QT event mechanism, so we can't just stall the event (we have to return 
to the caller). Actually, this might affect keystrokes as well, a tab can 
move focus but it may trigger an onLeave event which returns a value (false 
to stop the focus change) so there is the same problem :((

Maybe a general fix would have to be at the qApp->processEvents level; its 
maybe needs to be a bit like the event loop for a modal dialog, which filters 
events that are not destined for the dialog (eg., so repaints are allowed 
anywhere but mouse clicks only in the dialog). The progress dialog is the 
real culprit, because it is not a modal dialog, and can't be made modal - and 
in any case at some point I'd like to drop it and display progress in the 
form's status bar

Thinking hat goes on .....

Regards
Mike

>
> cheers
> Abel
> _______________________________________________
> Rekall-devel mailing list
> [email protected]
> http://www.mailman.a-i-s.co.uk/cgi-bin/mailman/listinfo/rekall-devel