The concurrency model that I'd like to see better supported in Nim is something along the lines of persistent data structures that support multiple-readers and a single-writer:
* Imagine an isolated graph of objects (refs). * This graph is be accessed through something like `SharedPtr[ref T]`, which would be the root of the graph. * The root can be safely shared between threads, and is the only object that participates in reference-counting for this graph. * The graph data structure is immutable/persistent, in the sense that it preserves the previous version of itself when it is modified, i.e., copy-on-write semantics, to avoid data races. * The graph can be modified safely by any number of threads concurrently, however concurrent updates result in different graph versions. A graph version is just another another root 'SharedPtr[ref T]`. (To be clear, a graph version is not a full copy of the graph -- it's merely a copy of the nodes that have been updated) * Writes can be batched so as to avoid generating excessive versions/garbage during graph updates. * Graphs can be connected to other graphs through other roots. * All graph updates have to ensure that the graph remains isolated, and require copying non-root refs from other graphs if needed. This model would be a great mid-point in the concurrency spectrum between being able to pass around (but not share) isolated graphs and having to `SharedPtr[T]` everywhere. It would be more convenient, preserve safety, and yet still be relatively efficient -- the additional object copies inherent to the persistent data structure model would be mitigated by avoiding the cost of fine-grained GC and concurrency control within the object graphs. My sense is this model is also compatible with the general direction of `lent` types, in that traversing an object graph in a read-only fashion would yield only `lent` types, and that updating a graph would involve hooks, similar in spirit to the lifetime-tracking hooks we already have, that would deal with updating (read: making copies of) the objects referencing the object being mutated (read: copied-on-write). I'm curious if the community would find this model compelling to have... (In the meantime, I'm using a poor-man's version of this model but using full mutability and big-giant-lock for readers/writers around the entire graph, which works okay but is neither very concurrency-friendly nor very elegant.)
