What is on Your Mind?

When you make copies of the memory, the memory won't propagate back unless you propagate it yourself. Which opens an even bigger can of worms than just using the originals -- when and if to propagate back.

If it's shared memory you don't make copies. You write to the shared memory and all processes that share that memory see the change. (The same would be true if "subshells" meant to operate on the same environment were threads instead of fork()'ed processes sharing memory - only the sharing mechanism differs.)

If you were saying that the "shell variables" (i.e. the shell's copy of all variables defined in the shell - the working copy shared with all shell processes or threads that are part of the current shell instance) don't propagate back to the "environment variables" (that is, the variables defined in "environ", accessible via C calls to getenv(), etc. in the shell's process) - they don't need to. The only time the shell needs to access its environment variables is at startup, to import those variables into its own working memory. When it runs a command, it forms a new environment including those variables that were exported...

(EDIT): I don't know, maybe I misunderstood you. I guess there is a side to this that I kind of glossed over. Are when you talk about the bigger can of worms, and when to "propagate back" - are you talking about cutting down on the accesses to the shared copy of the shell vars (and related semaphore actions) by pulling things in to a thread-local copy and then writing them back later? I guess that could be a bit of a headache...

What I was saying is that in this one specific case we're talking about, where one would implement shell threading by using forked processes and shared memory, you don't need to copy variable assignments back and forth between the processes. You make one copy and share it, using a semaphore system to keep from corrupting it. The only time you have to apply changes to (exported) variables back to the "environment" is when you're about to exec() - in that case you either need to modify the environment (modify "char extern **environ" with setenv(), etc.) to match the in-memory, shared copy, or else create a new environment for the program you're about to run by using execle() and feeding it a copy of those variables.

'Course, the whole thing (dealing with shared memory and fork()'ed processes and so on) sounds like a big headache if what I really want is threads. I suppose I can't count on every host platform having decent threads support, though...

Synchronization's fairly unavoidable with any sort of multiprocessing by whatever means, be it pipes, mutexes, shared memory...

Well, yeah. My point was just that there was no point going through all that - forking and sharing memory - just to simulate threads when I already have threads...