I wanted to be able to call a small program from the commandline, which
reads data from a hardware interface.  But I also need to have
configuration data read in from a file, but I only want to read this
data once, between consecutive calls, because this takes to much time.
How can I achieve some kind of persistent memory. I suppose I will have
to deal with more processes which talk to each other in some way, but how?

[ Post a follow-up to this message ]

"@(none)" <""jay\"@(none)"> writes:
quote:

> I wanted to be able to call a small program from the commandline,
> which reads data from a hardware interface.  But I also need to have
> configuration data read in from a file, but I only want to read this
> data once, between consecutive calls, because this takes to much time.
> How can I achieve some kind of persistent memory. I suppose I will
> have to deal with more processes which talk to each other in some way,
> but how?


The simplier is to fork a daemon  the first time, and to check for the
existance of  this daemon later  and send it  a signal to do  the work
instead of doing it in the command line process.

If it  needs to  be multi-user, then  signaling won't work  and you'll
need to  use a socket (IP  or unix) to communicate  between the daemon
and the command line.

Another architecture  would be to  have a configuration  server daemon
that would "publish" the configuration either thru socket (IP or unix)
or thru shared memory.

But  in any  case, the  "server" process  may be  swapped out,  or the
configuration  file  may be  buffered  in, so  it  may  not make  much
difference.

If you  really need to have  the data in  RAM at any time,  you should
lock in RAM the virtual memory pages where it's stored. See mlock(2).

--
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
* .  . /\  ()  . *
Living free in Alaska or in Siberia, a               . .  / .\   . * .
grizzli's life expectancy is 35 years,              .*.  / *  \  . .
but no more than 8 years in captivity.                . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: postmaster@sco.com                 ******************

[ Post a follow-up to this message ]

none wrote:
quote:

> I wanted to be able to call a small program from the commandline, which
> reads data from a hardware interface.  But I also need to have
> configuration data read in from a file, but I only want to read this
> data once, between consecutive calls, because this takes to much time.
> How can I achieve some kind of persistent memory. I suppose I will have
> to deal with more processes which talk to each other in some way, but how?


Some systems support interprocess shared memory.  Some don't.  In general,
if every process that uses the particular shared object exits, the object wi
ll

be destroyed and there is no help for that.  You could have some persistant
program, (even if it does nothing but sleep) lying around, holding the objec
t
in
existance.  The commands to use would be unique to your particular OS
(and probably to a version).  I would suggest living with reading a small
file, since it should take only a few tens of milliseconds.

Speaking only for myself,

Joe Durusau

[ Post a follow-up to this message ]

joe durusau <joe.durusau@lmco.com> writes:
[QUOTE]
>Some systems support interprocess shared memory.  Some don't.  In general,
>if every process that uses the particular shared object exits, the object will[/QUO
TE]

"In general" certainly doesn't apply to SysV shared memory or "mmap()"
shared memory backed by files.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

joe durusau <joe.durusau@lmco.com> writes:
quote:
 
>
> Some systems support interprocess shared memory.  Some don't.  In
> general, if every process that uses the particular shared object
> exits, the object will be destroyed and there is no help for that.


SysV shared memory stays put even if all processes exit.  It has to be
explicitly deleted.  I suppose POSIX shared memory can be used the
same way, but I haven't used it that much.
quote:

> You could have some persistant program, (even if it does nothing but
> sleep) lying around, holding the object in existance.  The commands
> to use would be unique to your particular OS (and probably to a
> version).  I would suggest living with reading a small file, since
> it should take only a few tens of milliseconds.


It depends on how big the file is and how much the contents need to be
processed.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

Thanks all for your suggestions. I'm about to read a tutorial about IPC
on Linux. This would be the way to go.
But this is getting to complicated now. I will let the configuration
stuff aside and let it be static (hard-coded at compile time) for now.
Reading a file will be to slow and unpredictable. The events I want to
log need to be measured with a granularity in the range of a few
milliseconds. I already had to change process priority (sched.h) in
order to have more stable reading times.

[ Post a follow-up to this message ]

"@(none)" <""jay\"@(none)"> writes:
quote:

> Thanks all for your suggestions. I'm about to read a tutorial about
> IPC on Linux. This would be the way to go.
> But this is getting to complicated now. I will let the configuration
> stuff aside and let it be static (hard-coded at compile time) for
> now. Reading a file will be to slow and unpredictable. The events I
> want to log need to be measured with a granularity in the range of a
> few milliseconds.


Then you need a hard realtime OS.  Standard Linux won't cut it.  Linux
2.6 might get you close, but with 2.4 it's more or less impossible.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

"@(none)" <""jay\"@(none)"> wrote:
quote:

>Thanks all for your suggestions. I'm about to read a tutorial
>about IPC on Linux. This would be the way to go.
>But this is getting to complicated now. I will let the
>configuration stuff aside and let it be static (hard-coded at
>compile time) for now. Reading a file will be to slow and
>unpredictable. The events I want to log need to be measured with
>a granularity in the range of a few milliseconds. I already had
>to change process priority (sched.h) in order to have more
>stable reading times.


I don't see the logic to what you've said.  If you are invoking
a program from a command line (as your previous post indicated),
even if done automatically, it will not get accurate
measurements within milliseconds, and the extra time to read a
configuration file is insignificant compared to invoking the
program itself (which requires reading in a much larger amount
of data, not to mention manipulating it.).

Your headers indicate you are using Linux, and assuming that is
the system this will run on I can't see where any change to
sched.h is going to affect your program.

Another factor is that you've indicated the data is coming from
a serial port... which has a 4k kernel buffer, and depending on
how you choose to read the data it is entirely possible that
your reads will necessarily occur in granules of between 10 and
20 milliseconds.  (If you switch to a 2.6.0-test?? kernel that
will be reduced to less than 1 millisecond, perhaps.)

You might want to expand on your description of what the program
does, and perhaps cross post this to comp.os.linux.development.apps
too.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]

Floyd Davidson wrote:
quote:

> I don't see the logic to what you've said.  If you are invoking
> a program from a command line (as your previous post indicated),
> even if done automatically, it will not get accurate
> measurements within milliseconds, and the extra time to read a
> configuration file is insignificant compared to invoking the
> program itself (which requires reading in a much larger amount
> of data, not to mention manipulating it.).


Arggh. I haven't thought about this overhead until now. How much time do
you think it may take on a pentium 900MHz? Good you pointed that out!
quote:

>
> Your headers indicate you are using Linux, and assuming that is
> the system this will run on I can't see where any change to
> sched.h is going to affect your program.


You got me wrong there. I meant setting another scheduling priority and
policy for this process using the functions declared in this headerfile.
quote:

> Another factor is that you've indicated the data is coming from
> a serial port... which has a 4k kernel buffer, and depending on
> how you choose to read the data it is entirely possible that
> your reads will necessarily occur in granules of between 10 and
> 20 milliseconds.  (If you switch to a 2.6.0-test?? kernel that
> will be reduced to less than 1 millisecond, perhaps.)


What I read is binary data from 7 times 8 bit 8255-compatible ports, so
parallel, not serial. We have two Data Acquisition Boards (PCI) in that
PC and there is a kernel driver for them.
quote:

> You might want to expand on your description of what the program
> does, and perhaps cross post this to comp.os.linux.development.apps
> too.
>


It shall be a programm to test other equipment which gets their commands
over LAN and which has digital outputs which are connected to my PC for
this testing purpose. Nothing really ambitious, but a small utility to
monitor synchronization among the appliances. It's a student project.

(btw I forgot to tell my real name to the mail-reader it's Jay
Christnach. I will change this now)

[ Post a follow-up to this message ]

"@(none)" <""jay\"@(none)"> wrote:
quote:

>Floyd Davidson wrote:
> 
>
>Arggh. I haven't thought about this overhead until now. How much
>time do you think it may take on a pentium 900MHz? Good you
>pointed that out!


There is just no way to predict what kind of response you'll
get.  It will probably never take longer than 10 seconds if the
usual time is less than 1/2 second...  hows that sound?

How fast are your disks? How much memory do you have?  But most
of all, what else is likely to be running on this system?

And even more significant, how can you guarantee that the
invocation itself is going to be uniformly at precisely the same
intervals?
quote:
 
>
>You got me wrong there. I meant setting another scheduling
>priority and policy for this process using the functions
>declared in this headerfile.


But again, that will not change the relationship between various
time constraints as the program is initialized.  It might change
the consistency with which data is acquired if the process then
reads data in a loop; but the worst case scenario for a non real
time OS is orders of magnitude worse than the average response
time.
quote:
 
>
>What I read is binary data from 7 times 8 bit 8255-compatible
>ports, so parallel, not serial. We have two Data Acquisition
>Boards (PCI) in that PC and there is a kernel driver for them.


Unless the _hardware_ samples at set intervals, you will not be
able to guarantee uniform data read intervals (using the OS).
quote:
 
>
>It shall be a programm to test other equipment which gets their
>commands over LAN and which has digital outputs which are
>connected to my PC for this testing purpose. Nothing really
>ambitious, but a small utility to monitor synchronization among
>the appliances. It's a student project.


Suitably vague enough to be virtually useless... :-(
quote:

>(btw I forgot to tell my real name to the mail-reader it's Jay
>Christnach. I will change this now)
>


--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]