Re: [gpsd-dev] Updated docs on NTP segment management

[Gary E. Miller]

Yo Hal!

On Wed, 25 Feb 2015 23:24:07 -0800
Hal Murray <address@hidden> wrote:

> 
> address@hidden said:
> > Well, the thing that had been byting me is the lack of a way to
> > mark an NTPSHM as 'in-use'.  If I am not really careful I get gpsd
> > and ptp4l both trying to step on shmid NTP0. 
> 
> That sounds like a vote for the client side to run in read-only mode.

Not sure how that helps solve the two competing server issue.

> > The root:rooot/600 and root:root/666 perms thing also recently bit
> > me. We gotta do ntpd:ntpd/660 or gpsd:ntpd:660. 
> 
> If the client side is read only, the permissions can be gpsd:gpsd:644.

No.  Then the sender would have to start first.  I like that the
sender or receiver can start first.

> > Another possibility, still noodling on it, would be to put a real
> > POSIX semaphore inside the SHM, so the slaves do not need to keep
> > polling, plus that give you a memory barrier for free. 
> 
> The basic structure of ntpd is single threaded.  The inner dispatcher
> does a select, so file descriptors get good response.  Can I do a
> select on a semaphore?  Is there a way to turn a semaphore or queue
> into something select can use?

Well, a couple things there.  ntpd needs to be threaded, then it makes
sense for a thread to wait on a semaphore.

> The other problem with semaphores is how to initialize them.

That is pretty easy.

> Remember that either ntpd or gpsd can start first and crash or
> restart at any time.  There may be a solution to that tangle, but I
> haven't seen one and this topic has been kicking around for a while.

I do not se a problem here.  A semaphore only blocks is another party to
the semaphore requests a block.  If only one side is runnning, no one to
block.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588