[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Updated docs on NTP segment management
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-dev] Updated docs on NTP segment management |
Date: |
Thu, 26 Feb 2015 00:23:13 -0800 |
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
- Re: [gpsd-dev] Updated docs on NTP segment management, (continued)
- Re: [gpsd-dev] Updated docs on NTP segment management, Miroslav Lichvar, 2015/02/23
- Re: [gpsd-dev] Updated docs on NTP segment management, Gary E. Miller, 2015/02/23
- Re: [gpsd-dev] Updated docs on NTP segment management, Harlan Stenn, 2015/02/23
- Re: [gpsd-dev] Updated docs on NTP segment management, Gary E. Miller, 2015/02/23
- Re: [gpsd-dev] Updated docs on NTP segment management, Miroslav Lichvar, 2015/02/25
- Re: [gpsd-dev] Updated docs on NTP segment management, Hal Murray, 2015/02/25
- Re: [gpsd-dev] Updated docs on NTP segment management, Gary E. Miller, 2015/02/25
- Re: [gpsd-dev] Updated docs on NTP segment management, Hal Murray, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management,
Gary E. Miller <=
- Re: [gpsd-dev] Updated docs on NTP segment management, Miroslav Lichvar, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Eric S. Raymond, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Miroslav Lichvar, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Eric S. Raymond, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Hal Murray, 2015/02/27
- Re: [gpsd-dev] Updated docs on NTP segment management, Hal Murray, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Eric S. Raymond, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Terje Mathisen, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Gary E. Miller, 2015/02/26
- Re: [gpsd-dev] Updated docs on NTP segment management, Harlan Stenn, 2015/02/26