Message: previous - next
Month: January 2013

Re: [trinity-devel] Potential risk of delays due to DNS in twin

From: "Timothy Pearson" <kb9vqf@...>
Date: Wed, 23 Jan 2013 19:33:03 -0600
> Hi all,
> I have a problem to discuss:
> Before long time I prepared a patch, which is included in the commit
> 9e3f8a7f.
> It was based on a completely broken patch for KDE4 - commit c24ea2b4. Our
> patch works correctly, but contains one potential risk - is dependent on
> => on the network delays.
> First question is, how big is this risk, because we have a patch
> incorporated
> nearly a year ago and no problems observed. The fact is that if the user
> will
> have a problem with the network, probably will not even be able to open a
> remote window. However, this risk actually exists.
> In my proposal for the integration of our patch into KDE4 was a risk
> discussed
> by KDE4 team and Martin prepared a solution where the DNS queries is
> executed
> in a separate thread - commit cbb7f575. In comparison with our patch it is
> quite big patch. Backport of Martin's patch is hampered by the fact that
> he
> was used QtConcurrent which is included in QT4.7 and higher.
> Therefore, I have a question: What next? Martin designed a simple revert
> our
> patch seems to me inappropriate. The second option is to leave our patch
> unchanged and also a risk. Third, that someone remakes patch to not use
> QtConcurrent (it is beyond my abilities).
> Your suggestions?
> Thanks for your comments and help
> Mentioned commits:
> Slavek
> --

I don't have the resources to work on this right now, but I would like to
mention that the current version of Qt3/TQt3 contains threading support
that was not present in Qt 3.3 and might be of assistance in solving this

The long term solution is for TDE to use a modified version of kwin, as
kwin has recently reached a level of stability and performance that makes
twin fairly obsolete.