18 Sep
2013
18 Sep
'13
5:10 p.m.
On Mon, Sep 16, 2013 at 10:14 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
You can fix thread-safety as it is usually fixed: put mutexes, rw
locks, etc. in right places of program and use thread-local variables.
You don't need to get into the deeps of Qt. And for sure, you don't
need to change API for that.
And from where I sit such work, multiplied across all of the multithreaded
programs in TDE, would be a *massive* waste of effort that would primarily
help to make TDE unmaintainable by all except the most elite hackers.
Fixing the problems *where they exist* makes it easier to use threading in
a stable, tested manner.
On Sat,
Sep 14, 2013 at 5:41 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
>> 2013/9/13 Aleksey Midenkov <midenok(a)gmail.com>
<snip>
There is no need in that. UI programs are not
high-load programs, they
don't
require bleeding edge performance optimization. Everything worked fine
there
before Trinity! You've digging wrong places. Do UI, not system libs.
So in other words, our users are supposed to just put up with frequent
unresolvable crashes that were traced back to fundamental flaws in
Qt3/TQt3, while we change the stable UI that our users expect us NOT to
significantly change? This is not 1999 anymore, users own systems with
multiple cores as a rule now, and some of the original KDE 3 code simply
was not thread safe! Sure, it worked most of the time on hyperthreaded
processors, but not on real multicore systems, just search our
bugtracker
for threading related bugs for a sampling of the problems *fixed* by
changing the TQt3 library. In fact, I suspect that you will only add instability,
not fix it. I
already had crashes on 13 (they were not too often before) and I've
read from people that noticed the same after they installed this
version.
Interesting, given that 3.5.13.x does NOT include ANY of the fixes we are
discussing, and therefore clearly demonstrates the problems that existed
*before* my fixes went in. Give R14 a try to see the difference.
As I have mentioned before, if you would like to see TDE on Qt4, why
don't
you figure out a way to port the entire codebase over, or at least start
porting components yourself? You will find that it is not an easy task!
Qt4 does not offer critical components that Qt3 did, and hacking around
the missing features *will* slow TDE down on many systems, just as KDE4
slowed down. (Yes, I have tried!).
I don't want Qt4. I'm Ok with everything except the UI. I said, that
if you want more sophisticated lib, then do it with Qt4, not modify
Qt3. If you say that Qt4 is missing something, I'm sure that there is
some solution with additional libs. I not quite understand, why moving
some functionality from Qt3 to KDE4 has slowed it down. Is it because
programmers at KDE worse, than at Trolltech? Again, there should
already be ready lib that does it good.