[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘ gpxlogger

From: Fred Wright
Subject: Re: ✘ gpxlogger
Date: Sat, 14 Aug 2021 15:49:14 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

On Thu, 12 Aug 2021, Gary E. Miller wrote:

Another fix to gpxlogger.  I hope the last.  Please test.

The problem was the lack of a timeout when reading gpsd from DBus.

I just pushed a fix for platforms lacking clock_gettime(). Aside from the needed include, the current fallback only implements CLOCK_REALTIME, which is the only type that's been used so far, and it's generally fine for timeouts. For really accurate intervals, one should use CLOCK_MONOTONIC_RAW, not CLOCK_MONOTONIC, since the latter only omits the step adjustments, and still includes the same intentional rate errors for slewing as CLOCK_REALTIME, typically on the order of 500ppm. CLOCK_MONOTONIC is pretty much never what you really want.

With the timeout it indeed now only hangs for five seconds instead of forever waiting for dbus, though ^C still has no effect as expected.

In the process, I did some testing with and without dbus running, and found that gpxlogger is never able to find the local gpsd without dbus, even in the perfectly normal case where gpsd is running with a receiver providing fixes. Meanwhile, cgps has no trouble. I suspect that the dbus failure is failing to fall back to the non-dbus method of connecting.

No other client uses gps_mainloop() so many bugs in there...

Indeed.  It still nees to interact better with signals.

Fred Wright

reply via email to

[Prev in Thread] Current Thread [Next in Thread]