hypfvieh / dbus-java

Improved version of java DBus library provided by freedesktop.org (https://dbus.freedesktop.org/doc/dbus-java/)
https://hypfvieh.github.io/dbus-java/
MIT License
185 stars 73 forks source link

Potential issues by using non-monotonic clocks #206

Closed ghost closed 1 year ago

ghost commented 1 year ago

There are a few invocations of non-monotonic clocks that may require closer examination. These include:

            Message.marshallintBig(System.currentTimeMillis(), buf, 0, 8);
// ...
            long start = System.currentTimeMillis();
// ...
            while (lCookie == null && (System.currentTimeMillis() - start) < LOCK_TIMEOUT) {

This one would depend on how the marshalled ID is used:

                    long id = System.currentTimeMillis();
                    byte[] buf = new byte[8];
                    Message.marshallintBig(id, buf, 0, 8);

I couldn't find anything else of note with respect to non-monotonic time.

hypfvieh commented 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.