I don't know the details of what you are doing, but the other possibility you may consider is the use of a immutable-functional language, which can share immutable values without duplication but doesn't let you get into too much trouble. (Of course you're probably on top of things now, but when I need to write a new program like this I reach for the immutable-functional languages now unless I absolutely can't use them. Fortunately, Erlang is an option at work for me.)
The way you are using those words leads me to believe you don't know how they work in these languages; I feel you are using them synonymously with the operating system's idea of threads and forks. In fact that is not true; both Haskell and Erlang can run in a single OS process, while handling threads internally to their own runtime. They don't all the time, but they can. In more conventional languages this is called green threads, in the functional world it's simply how it is done.
I did say "I feel" because I could be wrong, but there are still a lot of people who think that the operating idea of a thread is still the only possible meaning of the term (I meet them every time Node.js comes up and the Node.js partisans argue passionately against operating system threads), but those days are long gone. So even if you do understand this, there are others who don't.
Comments
I don't know the details of what you are doing, but the other possibility you may consider is the use of a immutable-functional language, which can share immutable values without duplication but doesn't let you get into too much trouble. (Of course you're probably on top of things now, but when I need to write a new program like this I reach for the immutable-functional languages now unless I absolutely can't use them. Fortunately, Erlang is an option at work for me.)
Sure, but you'd still need a thread or a fork to take advantage of the immutable object from more than one execution context without duplication.
The way you are using those words leads me to believe you don't know how they work in these languages; I feel you are using them synonymously with the operating system's idea of threads and forks. In fact that is not true; both Haskell and Erlang can run in a single OS process, while handling threads internally to their own runtime. They don't all the time, but they can. In more conventional languages this is called green threads, in the functional world it's simply how it is done.
I did say "I feel" because I could be wrong, but there are still a lot of people who think that the operating idea of a thread is still the only possible meaning of the term (I meet them every time Node.js comes up and the Node.js partisans argue passionately against operating system threads), but those days are long gone. So even if you do understand this, there are others who don't.