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: http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=c24ea2b4aac2... http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c71... http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe2...
Slavek --
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: http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=c24ea2b4aac2... http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c71... http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe2...
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 problem.
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.
Tim
On Thursday 24 January 2013 00:54:50 Slávek Banko wrote:
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,
actually it doesn't as I figured out while working on the new patch: a remote libre office window is marked as local.
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.
this is unrelated to remote windows. The problem would show itself also for local windows and that is in fact not such an unlikely situation. While coming from suspend my system takes about half a minute to minute to reconfigure the network. This would be the critical interval in which one is not allowed to open libre office.
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).
third option is IMHO impossible. The interaction of the newly designed classes was highly influenced by what is possible with QtConcurrent. It would need a complete different approach by using the async variant.
As written I suggest to revert the patch as the risk is too high. In KWin we have the requirement to have no blocking call. It's extremely nasty if the compositor is blocked - this means system is frozen. For just window manager it's not as bad. You can no longer interact with windows.
Cheers Martin
In article 201301240054.50984.slavek.banko@axis.cz, Slávek Banko trinity-devel@lists.pearsoncomputing.net wrote:
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.
It is possible that one DNS lookup may freeze for a while on a generally working link, if you hit a DNS server that does not respond.
I have my suspicions about Plasma on KDE4 but I haven't noticed this causing any general hang on Trinity up to 3.5.13.
Nick
On Friday 25 January 2013 22:54:55 Nick Leverton wrote:
In article 201301240054.50984.slavek.banko@axis.cz,
Slávek Banko trinity-devel@lists.pearsoncomputing.net wrote:
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.
It is possible that one DNS lookup may freeze for a while on a generally working link, if you hit a DNS server that does not respond.
this is exactly the reason why we have not integrated the patch into KWin.
I have my suspicions about Plasma on KDE4
sorry I do not get what you want to say with this comment
but I haven't noticed this causing any general hang on Trinity up to 3.5.13.
which says exactly: nothing. You would only be able to hit the problem if you start an application setting a FQDN name (e.g. libre office) and DNS not working at this time. Most probably chance: session restore.
-- Martin Gräßlin
-
Martin Gräßlin -
Nick Leverton -
Slávek Banko -
Timothy Pearson