[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] gpsd and shared memory
From: |
Ed Simmons |
Subject: |
Re: [gpsd-users] gpsd and shared memory |
Date: |
Mon, 5 Oct 2015 09:53:07 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
Hi Gary, Roger,
On 05/10/15 09:28, Roger Oberholtzer wrote:
> ________________________________________
> From: Gary E. Miller address@hidden
> Sent: Friday, October 02, 2015 9:07 PM
> To: Roger Oberholtzer
> Cc: address@hidden
> Subject: Re: [gpsd-users] gpsd and shared memory
>
> Yo Roger!
>
> On Fri, 2 Oct 2015 06:54:20 +0000
> Roger Oberholtzer <address@hidden> wrote:
>
>> I think you may be the first person to use the shared memory interface. It
>> is relatively new and probably only esr knows how it works.
> I like to go off in places with few others blocking the scenery...
>
>> It does not know it is 'new', but it does know it is valid or atomic. When
>> the bookends match the the data was read in a consistent state.
> I guess I am trying to figure out why there is both a barrier and the
> bookends. The barrier, I would imagine, ensures that the shm reader has
> exclusive access so the contents do not change during the copy. If that is
> the case, what purpose are the bookends? There is a comment in the code, but
> it is unclear to me what is really trying to be accomplished. Are the
> bookends some mechanism to determine if the contents have changed since a
> previous copy of the data? Or something obtuse?
>
>> Doing shared memory is a twitchy thing, note the comments on barriers,
>> read/write order, etc. So just use the function, dont try to duplicate it.
> I have used shared memory in other situations to great effect. It is all in
> what you claim to be putting in the segment that decides the degree of
> twitchiness.
>
>> Which iis a good reasson not to use this interfacec, but to use a socket
>> instead.
> Yeah, but that changes the access logic I am hoping to implement.
>
> Roger Oberholtzer
>
> RST Systems
>
> Office: +46 (0)10-615 6020
> Mobile: +46 (0)70-815 1696
> address@hidden
> ________________________________________
>
> Ramböll Sverige AB
> Krukmakargatan 21
> P.O. Box 17009
> SE-104 62 Stockholm, Sweden
> www.rambollrst.se
>
Just my 2 cents, we used the shared memory interface with no problems on
a project which is sadly now defunct. The client was a c program reading
GPSD data (including some extra marine sensors that we added to GPSD)
that wrote data to a mysql database according to some settings it read
from a state table. This worked really well for our needs and I'd say
you have no worries making use of it!
--
Ed Simmons
address@hidden
www.estechnical.co.uk
- [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Gary E. Miller, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Gary E. Miller, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory,
Ed Simmons <=
- Re: [gpsd-users] gpsd and shared memory, Gary E. Miller, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Gary E. Miller, 2015/10/08
- Message not available
- Message not available
- Message not available
- Re: [gpsd-users] gpsd and shared memory, Roger Oberholtzer, 2015/10/08
- Re: [gpsd-users] gpsd and shared memory, Gary E. Miller, 2015/10/08
Re: [gpsd-users] gpsd and shared memory, Jon Schlueter, 2015/10/08