Quote:
Originally Posted by
Corona688
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...