Hi Patrick, On 2/19/26 5:31 PM, Patrick Jacobs wrote:
I appreciate your response! I have previously read through the attached threads before my first message, and I think I explained myself poorly, linguistically mixed up shared-memory concurrency with isolated parallelism. My suggestion is explicitly because of the reference-counting in GiNaC. When I mention “contexts," I mean isolated object hierarchies. In this model, we would never share the same underlying basic object (memory address) between threads. Instead, when we want to move work to another thread, we would perform a deep copy (or "export/import") of the expression. Ideally, x in Context A and x in Context B would be two completely distinct objects in memory, each with its own independent reference counter. Thread A only touches the refcounts in its pool, and Thread B only touches the refcounts in its pool. My question is essentially: Is the current global state (like the symbol registry or CLN internals) tightly coupled in a way that prevents us from having these two isolated "islands" of objects coexisting in the same process? I'm asking if we can use multiple contexts (worlds) to split up work on expressions and pass equivalent representations of expressions to different contexts. Forgive me if I am making a nonsensical suggestion.
Oh, great question! No, not a nonsensical suggestion at all. Yes, there would be some silent coupling between the pools. Have a look at the the number expressions initialized in the library_init ctor in utils.cpp, for example. But with some reasonable effort, it should be possible, I guess, to split all this into per-thread pools and then use them only per-pool in parallel. It could be worth trying. -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>