23 Jan
2013
23 Jan
'13
11:54 p.m.
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=c24ea2b4aac…
http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c7…
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe…
Slavek
--
24 Jan
24 Jan
1:33 a.m.
New subject: [trinity-devel] Potential risk of delays due to DNS in twin
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=c24ea2b4aac…
http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c7…
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe…
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
25 Jan
25 Jan
7:34 a.m.
New subject: [trinity-devel] Potential risk of delays due to DNS in twin
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
10:54 p.m.
In article <201301240054.50984.slavek.banko(a)axis.cz>cz>,
Slávek Banko <trinity-devel(a)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
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
27 Jan
27 Jan
7:23 a.m.
New subject: [trinity-devel] Re: Potential risk of delays due to DNS in twin
On Friday 25 January 2013 22:54:55 Nick Leverton wrote:
In article
<201301240054.50984.slavek.banko(a)axis.cz>cz>,
Slávek Banko <trinity-devel(a)lists.pearsoncomputing.net> wrote:
this is exactly the
reason why we have not integrated the patch into KWin.
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
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
4104
days inactive
4108
days old
4 comments
4 participants
participants (4)
-
Martin Gräßlin -
Nick Leverton -
Slávek Banko -
Timothy Pearson