My app uses a shared library that is linked into a number of programs,
which tend to execute one another. The library communicates some state
information between instances of itself in parent and child processes
via the environment.

This generally works but occasionally it runs into a conflict with the
program's own use of the environment. I've been able to solve all the
issues that have come up to date, but I'm starting to wonder if it might
not be more elegant and robust to handle this communication in a
"private" env block. I.e. implement something custom that's a block of
strings like the environment and is inherited parent to child but is
hidden from getenv/putenv and thus does not pollute the "real" environment.

Does anyone have suggestions for which IPC mechanism would be best?
Shared memory doesn't seem quite right because each process would be
allowed to modify its block and pass it on to its children, so for N
children there might be N different copies.

Thanks,
HT

[ Post a follow-up to this message ]

>My app uses a shared library that is linked into a number of programs,
>which tend to execute one another. The library communicates some state
>information between instances of itself in parent and child processes
>via the environment.
>
>This generally works but occasionally it runs into a conflict with the
>program's own use of the environment. I've been able to solve all the
>issues that have come up to date, but I'm starting to wonder if it might
>not be more elegant and robust to handle this communication in a
>"private" env block. I.e. implement something custom that's a block of
>strings like the environment and is inherited parent to child but is
>hidden from getenv/putenv and thus does not pollute the "real" environment.

Command-line arguments might work for what you are describing.
(or perhaps one command-line argument with all the variable=value
parameters packed into one argument).

Gordon L. Burditt

[ Post a follow-up to this message ]

Gordon Burditt wrote:
> Command-line arguments might work for what you are describing.
> (or perhaps one command-line argument with all the variable=value
> parameters packed into one argument).

Good point, except that in this case the behavior of the "host" programs
(those linked with the library) must not be affected. They'll have their
own argv parsing behavior which I can't change so I'm looking for
something that can be handled entirely within the library code. In its
initializer, or maybe the first time some entry point within it is
called, it wants to say "hmmm, what does my parent have for me?" and
process it. Otherwise I'd just be exchanging potential env conflicts for
potential argv conflicts.

Thanks,
HT

[ Post a follow-up to this message ]

well, you need to figure out what ties the various instances of
programs using
these libraries together.. e.g. are they all children of the same
process, or is there
something else you can use?  Once you have that unique thing, create a
filename
using that unique id and have each app read that file via your library.

You'll need to handle the same user running multiple instances of the
same
program, etc.

- Bart

[ Post a follow-up to this message ]

bart.smaalders@gmail.com wrote:
> well, you need to figure out what ties the various instances of
> programs using
> these libraries together.. e.g. are they all children of the same
> process, or is there
> something else you can use?

Is there some part of "... a block of strings like the environment and
inherited parent to child ..." that's unclear? :-) The point here is to
emulate the behavior of the environment as closely as possible without
affecting the 'environ' pointer or getenv/putenv, etc.

> Once you have that unique thing, create a filename
> using that unique id and have each app read that file via your library.

Just to make sure, you're speaking of a different file per process,
uniqified via the pid or similar? There will be a potentially deep
process hierarchy and each process will want to modify its "environment"
before passing it down.

Thanks,
HT

[ Post a follow-up to this message ]