[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.
http://bugs.kde.org/show_bug.cgi?id=86993
------- 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