[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
From:       Matt Whitlock <bugzilla_noreply () kde ! org>
Date:       2016-11-30 19:00:17
Message-ID: bug-368438-17878-AUFEthy9a0 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=368438

--- Comment #8 from Matt Whitlock <kde@mattwhitlock.name> ---
(In reply to Albert Vaca from comment #7)
> Is there a way I can reproduce it?

I'm not sure. KDE Connect is broken for me more often than it works, and I
still don't know the exact conditions that cause it to enter the failure mode.
I know that rebooting my phone makes it work again for a while. In fact, I did
that just now, and now KDE Connect is connected and I can ring my phone from my
computer's KDE Connect tray panel.

> Does simply adding volatile fixes it for you?

I don't have an Android development environment, and I don't know the first
thing about developing apps for Android. I'm a Java developer, not an Android
developer.

> If this was the case, there are probably many more volatile
> missing, so I would like to have a way to check the effect of
> adding/removing them.

Data races are probabilistic and as such are notoriously difficult to reproduce
reliably, as they depend on factors outside of the program being tested, such
as the global state of the operating system and the specifics of the OS
kernel's thread scheduler.

Rather than measuring the effects of declaring variables volatile, which sounds
a lot like "programming by accident"
(https://en.wikipedia.org/wiki/Programming_by_permutation), you should reason
about which variables need to be declared volatile. Generally, if you access a
variable from more than one thread without any kind of synchronization between
the threads, then you must declare the variable volatile.

And for what it's worth, Thread.sleep(…) is not a synchronization primitive. In
general, there is no upper bound on the amount of time that a thread may be
paused between instructions, so you cannot pick any delay time for
Thread.sleep(…) that is guaranteed to be long enough. Use proper thread
synchronization techniques instead.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]