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

List:       gpsd-dev
Subject:    =?UTF-8?Q?Re=3A_=E2=9C=98_gpxlogger?=
From:       Fred Wright <fw () fwright ! net>
Date:       2021-08-14 23:17:13
Message-ID: alpine.OSX.2.23.453.2108141607410.9783 () macpro ! local
[Download RAW message or body]


On Sat, 14 Aug 2021, Gary E. Miller wrote:
> On Sat, 14 Aug 2021 15:49:14 -0700 (PDT)
> Fred Wright <fw@fwright.net> 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.
>
> Thanks!
>
> 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
> with:
>        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

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