[Kst] [Bug 86993] Statusbar element placement is awkward

George Staikos staikos at kde.org
Wed Aug 11 22:33:21 CEST 2004

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

------- Additional Comments From staikos kde org  2004-08-11 22:33 -------
On Wednesday 11 August 2004 16:07, Barth Netterfield wrote:
> will what we have now impact stability of 0.99?

  I'm not entirely sure.  We did have problems with this before where events 
would come through that we weren't prepared to handle.  I've been tracing 
through all the code that uses it and it doesn't seem like any locking is 
used at this time besides the global list lock for vectors.  That's a bug in 
and of itself that needs to be fixed.  Meanwhile once these locks are in 
place, we need to make sure that all locks are released around areas that 
call out to the progress bar, then reobtained immediately after (and hope 
that we don't deadlock then, which I think is a safe bet).  One of my big 
concerns is for realtime updates.  What happens if the  Xvector changes while 
the data is being loaded?  We can't hold the read lock, so we would have to 
keep it outside the global list.  Then we have curves pointing to vectors not 
in the global list, so we have to keep the curves out of the global list (etc 
etc).  The code in the data wizard is not prepared to deal with this.  If we 
hold the read lock all the way through, we can definitely deadlock.

   This is just one possible conceptual problem with processing events.  I did 
spend quite some time trying to produce a deadlock or crash and haven't been 
able to yet, but that doesn't mean we aren't introducing one by any means.

   All in all, I'm worried about this, which is why I didn't have this fixed a 
long time ago.

More information about the Kst mailing list