Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24325
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Embedded Linux: share data among different processes |
| Date | 2016-06-24 10:44 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <nkjri9$5el$1@dont-email.me> (permalink) |
| References | <nkgihf$dn7$1@dont-email.me> <nkhca7$cuk$1@dont-email.me> <nkj67u$oer$1@dont-email.me> |
On 6/24/2016 4:40 AM, pozz wrote: > Il 23/06/2016 21:11, Don Y ha scritto: >> It depends on how "lightweight" you want the mechanism to be. And, >> how "elegant". >> >> If you can implement the "Shared Memory" extensions (a kernel option >> in the *BSD's -- not sure re: Linux) then this is the easiest way >> forward. Look for shmget(2), shmat(2), shmctl(2), et al. >> >> Use a semaphore to control access (and discipline for thereaders/writers >> to follow that convention) and keep atomic regions short and sweet. >> >> If the data isn't changing all that often, you can push it to each >> consumer through pipes and count on them to keep their own copies >> intact. (here, there be dragons) > > There are some analog signals that could change every second. The poller will > fetch new updated data about every one second. I would avoid pushing new data > to consumers (HTTP server and QT libraries) every second. Ask yourself what the finest granularity you need/want in the data. Is it one big block of data that only makes sense as a whole? Or, lots of smaller blocks that can stand on their own? E.g., if you were reporting meteorological data (wind speed, air temp, humidity, barometric pressure, etc.), allowing <someone> to see *one* of these updated without the others being simultaneously updated could lead to a faulty forecast (because forecasts rely on the interpretation of ALL of the results, in concert). >> The DBMS approach is how I am currently addressing all "persistent >> data". It's a fair bit heavier-handed (I've got lots of MIPS to spare) >> but is more elegant; > > I will have a lot of spare MIPS too. "A lot" can have different meanings to different people :> > I don't need to save data in a persistent way (after a reboot, the poller will > start to retrieve new data). > I thought to create the SQLite database file in a RAM/temporary filesystem. > This should speed up the access and should avoid Flash memory corruption. You typically would NOT want to be updating those <things> in FLASH as you'll wear out the FLASH in short order. Note that data in a DBMS typically is "larger" than you would achieve if storing in a single, typed variable (before adding the overhead of indexes, etc.). And, you will also require resources for the WAL, if supported. I.e., before you make this DBMS decision, you might want to throw together a simple schema and store your dataset to see just how big it ends up. You should also think about how you will be interacting with the data. E.g., returning to the weather report analogy, if you are planning on cherry picking one value at a time from the *set* of values, then you risk reporting data that "doesn't make sense" -- because the "temperature" you reported a moment ago doesn't correspond to the "barometric pressure" you are reporting now. You may need to approach the data transactionally and, if you don't want to lock up the DBMS while your client process chugs along at *its* pace, this might require you to introduce some transaction buffering *between* the two entities -- which might not have been in your original design plans. Lastly, if you settle on that approach, "unconstrain your thinking" in considering what you *could* do with data thusly "organized". I found that lots of code that I'd have normally placed in the application (i.e., client) can be pushed back into the RDBMS and the way I *think* about the data that it supplies. >> a producer can't inject data into the store >> unless the data is appropriate for the tables/fields involved >> (you can't store text somewhere that expects numerics!). Likewise, >> the consumers need not *check* the data because the checks can be >> applied on admission to the DB. I.e., if the data is *in* the >> DB, then you know it satisfied the admission criteria! >> >> However, I don't think SQLite has all of these hooks. >> >> GNeuner is your go-to guy for the DB approach...
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-23 13:52 +0200
Re: Embedded Linux: share data among different processes Jack <jack4747@gmail.com> - 2016-06-23 05:30 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-23 21:05 +0800
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 09:45 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 17:19 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 13:25 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 21:27 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 14:40 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 22:20 -0700
Re: Embedded Linux: share data among different processes Clifford Heath <no.spam@please.net> - 2016-06-24 17:19 +1000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 01:01 -0700
Re: Embedded Linux: share data among different processes Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-24 16:38 +0300
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 11:13 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-24 12:39 +0800
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 01:53 -0700
Re: Embedded Linux: share data among different processes Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 09:34 +0800
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:30 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 15:18 -0500
Re: Embedded Linux: share data among different processes Mel Wilson <mwilson@the-wire.com> - 2016-06-23 13:47 +0000
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:36 +0200
Re: Embedded Linux: share data among different processes Mel Wilson <mwilson@the-wire.com> - 2016-06-26 15:25 +0000
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-23 12:11 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:40 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 10:44 -0700
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-23 12:31 -0700
Re: Embedded Linux: share data among different processes George Neuner <gneuner2@comcast.net> - 2016-06-23 17:27 -0400
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:43 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 10:48 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-27 14:46 +0200
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-27 13:41 -0700
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-24 13:52 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 16:42 -0500
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-27 16:00 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-27 20:06 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-28 08:41 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-28 00:27 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-28 12:50 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-28 10:01 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-29 13:10 +0200
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-29 10:47 -0700
Re: Embedded Linux: share data among different processes edward.ming.lee@gmail.com - 2016-06-29 14:01 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-30 15:11 +0200
Re: Embedded Linux: share data among different processes edward.ming.lee@gmail.com - 2016-06-30 08:19 -0700
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-23 14:53 -0500
Re: Embedded Linux: share data among different processes Paul Rubin <no.email@nospam.invalid> - 2016-06-23 13:05 -0700
Re: Embedded Linux: share data among different processes pozz <pozzugno@gmail.com> - 2016-06-24 13:54 +0200
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 14:27 -0500
Re: Embedded Linux: share data among different processes Les Cargill <lcargill99@comcast.com> - 2016-06-24 16:39 -0500
Re: Embedded Linux: share data among different processes Don Y <blockedofcourse@foo.invalid> - 2016-06-24 15:11 -0700
csiph-web