[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] gpsd and shared memory

From: Gary E. Miller
Subject: Re: [gpsd-users] gpsd and shared memory
Date: Fri, 2 Oct 2015 12:07:48 -0700

Yo Roger!

On Fri, 2 Oct 2015 06:54:20 +0000
Roger Oberholtzer <address@hidden> wrote:

> I see that the interface to shared memory is not that I do the access
> myself. gps_read does this. So I was curious how it did this. I have
> what is perhaps a silly question about  gps_shm_read (listed below).
> I see that the first memcpy() copies data into local storage. What I
> am curious about is:

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.

>  - Is gps_read differentiating between there not being new
> information in the shared memory segment since the last read or that
> the memory changed while reading it?

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.

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.

>  - If before != after (the data changed while being read?), then the
> read returns that there is no data?

Yup, at least no atomically consistent data.  So a retry would be in
order after a pause.

Which iis a good reasson not to use this interfacec, but to use a
socket instead.

> So old data would be returned each time, and only if the data
> changed while accessing the data would gps_read say there is no data?

Well, all the consistent data is always old.

>  - And if the data did not change, there is a second copy of the
> data? 

Not that I see in gps_shm_read().

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

Attachment: pgpSMsUKaGbfK.pgp
Description: OpenPGP digital signature

reply via email to

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