> I consider shared a dead-end for modular program construction: Say you have a > library like json.nim that needs to allocate: Should these allocations be > thread-local? Then you cannot use it across threads easily, inflexible. > Should it use shared allocations? Then the very common single threaded case > becomes slower.
@Araq, so what's the solution? One common heap, and it's up to the individual use case to add the locks and atomic access through override wrappers when it is necessary to make it thread safe? I guess we could live with that: the general case is to make it easy and fast, and one just adds the "hooks" as far as necessary to make it thread-safe; I suppose there could even be a standard way of adding the "hooks" without writing the boilerplate code oneself and just casting to a distinct alternate type. That's why I suggested that shared would just be a qualifier something like owned which just changes the "hooks". a seq is whatever it is but when cast to a shared seq (a distinct type), it automatically gets a new set of [] and []= hooks that provide atomic access, and also different move semantics, assignment, and destruction, all for just carrying a Lock field around whether it gets used (for the shared version) or not (for the normal unshared version). This is anomalous to a ref being a normal ref until cast, converted, or moved, into an owned ref in which case the "hooks" change.
