[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.


> 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 


> 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 

These are my opinions.  I hate spam.

reply via email to

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