[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 16:17:13 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

On Sat, 14 Aug 2021, Gary E. Miller wrote:
On Sat, 14 Aug 2021 15:49:14 -0700 (PDT)
Fred Wright <> wrote:

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.


I just notice the CLOCK_MONOTONIC is not good for timeouts.  From the
man page:

   "This clock does not count time that the system is  suspended."

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.

I'm not sure what you expected?  ^C now working for me, but maybe we
have different tests?

I mean that one has to wait for the timeout; typing ^C is ignored in the meantime.

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.

By default, gpslogger only tries DBus.  To use TCP, you have to start
       gpxlogger localhost

or specify the export method:
       gpxlogger -e shm
       gpxlogger -e sockets

Fallback was never part of the gps_mainloop() code.

Sounds like another deficiency in gps_mainloop(). Other clients don't have this issue. Or do other clients not use dbus at all?

Meanwhile, cgps has no trouble.  I suspect
that the dbus failure is failing to fall back to the non-dbus method
of connecting.

I make no assumptions.  No other gpsd client has ever used gps_mainloop()
and that function is way more complicated than I expected.

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

Indeed.  It still nees to interact better with signals.

What exactly is failing for you?

See above. Hanging uninterruptibly for five seconds is certainly an improvement over hanging forever, but there's no good reason why it should be uninterruptible at all.

Fred Wright

reply via email to

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