Closed ghost closed 1 year ago
I removed the usage of System.currentMillis()
.
In case where some sort of "wait for lock" was used, I now use TimeMeasure
. It was originally intended for debugging only (measuring runtimes). I updated the code of TimeMeasure
to use System.nanoTime()
and added the required function for the measuring the locking stuff.
Regarding the duplicated code: No EmbeddedDBusDaemon::startInBackgroundAndWait
cannot be removed. It is public API.
I moved the wait stuff to a more generic method in Util
. Now the Util.waitFor
method is called when waiting for something is required.
There are a few invocations of non-monotonic clocks that may require closer examination. These include:
org.freedesktop.dbus.utils.TimeMeasure
-- I think this class isn't used and can probably be deleted to prevent its use in the future.org.freedesktop.dbus.connections.SASL
-- Issue #205 notes a few occurrences of possible non-monotonic clock issues. There may be more, including:This one would depend on how the marshalled ID is used:
EmbeddedDBusDaemon::startInBackgroundAndWait
,RunDaemon::startDaemon
, andRunTwoPartDaemon::startDaemon
have effectively duplicate code blocks for busy-waits. I thinkstartInBackgroundAndWait
can be removed. If not, consider refactoring the duplication to make finding and reviewing the code for potential timing-related issues easier.AbstractBaseTest
andAbstractDBusBaseTest
also duplicate the same code. These could be refactored to simplify the code base and make finding potential timing-related issues easier.I couldn't find anything else of note with respect to non-monotonic time.