[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SHM refclock improvements
From: |
Hal Murray |
Subject: |
Re: [gpsd-dev] SHM refclock improvements |
Date: |
Tue, 28 Aug 2012 16:54:39 -0700 |
> gpsd is still fighting with major distros not updated to gpsd 3.x yet.
Sigh.
> Should be simple to come up with a simple way to determine protocol version.
Why should that be simple? It's the same problem as passing time-stamps from
gpsd to ntpd, maybe even more complicated since you might want to go both
directions.
----------
> So, any reason NOT to go to named pipes like chronyd?
It's certainly worth considering.
Is the API stable? Is there any documentation?
I haven't used pipes for anything tricky like this. Is there a good FAQ?
Basically, ntpd is single threaded, no locks, driver code can't block.
ntpd has 2 modes for IO.
One is polled: the system calls each driver once a second. This is what the
SHM driver does.
The other is a giant select: the system calls the right chunk of code when
there is data to read. Unless I've missed something, this mode doesn't know
how to reopen devices that get closed. So if you trip over your USB cable,
that slot is dead until you restart ntpd. I assume restarting gpsd would
have the same problem if we used it this way.
I think we could do it all with polling. That's assuming open doesn't block.
Or somebody could fix ntpd to reopen dead devices. That would be handy for
other cases.
---------
> Threads are so controversial and non-portable I would prefer not to touch
> that idea.
What's the problem with threads? I grew up with them (30+ years ago) so I
never had any serious troubles.
Is the problem threads in general, or pthreads in particular?
I know of two general problem areas. One is locks. The other is
who-calls-who?
--
These are my opinions. I hate spam.
- [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Hal Murray, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Dave Platt, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements,
Hal Murray <=
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
Re: [gpsd-dev] SHM refclock improvements, Miroslav Lichvar, 2012/08/29