Message: previous - next
Month: January 2013

Potential risk of delays due to DNS in twin

From: Slávek Banko <slavek.banko@...>
Date: Thu, 24 Jan 2013 00:54:50 +0100
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 DNS 
=> 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: