[Kst] kdeextragear-2/kst/kst

[George Staikos]

On Friday 09 July 2004 14:08, Barth Netterfield wrote:
> Its in the UI thread, which is all event driven anyway.  And the call is
> about to be made several lines later when we leave the event handler.

   The problem is that we process an event while we are in the middle of 
another event.  I had to fix this in the past by putting hacky guards in the 
most problematic places.

> The point is this: we *have* to block the update thread until *all* of the
> events are finished being processed... And we don't know what those events
> are.  This fixes it.  Without doing this, kst is essentially unusable in
> real time mode.  Doing this, it seems pretty OK.
>
> Is the worry is that there could be a 'quit' event processed in the call?
> Don't know what that would do.  Update thread stays blocked in usleep land?
> Everything else seems pretty safe.

    True, we could definitely get that.  We could also have a situation like 
this:

Data wizard -> Finish -> events are processed due to progress dialog
Update event comes through -> update dialogs (already looking bad)
New event loop entered, more data wizard processed
         -> dcop calls, paints, other events processed
   (meanwhile updates are still frozen)

   This is basically going down the same road we travelled before.  (yes it 
was still possible to crash Kst before too - just difficult in the common 
case)

> The problems we were having in the old scheme were related to interactions
> between what is now in the update thread and what is now in the UI thread.
> These are now fixed.  The only thing happening in the update thread here is
> usleeping...  I think its safe.

   The problem is not related to the update thread in any way, although it 
could make it worse if it sent events while we were in the loop.  Clearly it 
doesn't right now.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/