[Kst] kdeextragear-2/kst/kst

[Barth Netterfield]

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 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.

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.  

cbn

On July 9, 2004 01:46 pm, George Staikos wrote:
> On Friday 09 July 2004 12:07, Barth Netterfield wrote:
> > CVS commit by netterfield:
> >
> > Real time updating was not working, because the paint events were not
> > actually being processed before giving the 'all clear' to the ui thread.
> > This fixes that, and improves on the clarity of the comments in the
> > update thread.
> >
> >
> > --- kdeextragear-2/kst/kst/kstdoc.cpp  #1.96:1.97
> > @@ -797,5 +797,6 @@ bool KstDoc::event(QEvent *e) {
> >      } else if (te->_eventType == ThreadEvent::Done) {
> >      }
> > -    _updating = false; // ok, we're done...
> > +    kapp->processEvents(); // actually do the paints and check for
> > inputs +    _updating = false; // ok, we're done... update thread can
> > send us a new event.
>
>    This patch really scares me.  It's part of what the whole multithreading
> design was supposed to eliminate - re-entering the event loop.  We had
> loads of weird crash cases in the old single-threaded code because of these
> calls.