mm:sharedOrc

Well it depends on the overhead they introduce and how good the tooling (sanitizers, custom annotations for static tools?) becomes at detecting data races. Swift, for example started with what is basically `mm:atomicArc` and introduces isolation too, to prevent data races at compile-time:

mm:sharedOrc

Is the plan to eventually replace - -:arc with - -mm:atomicArc (hopefully by renaming “atomicArc” to just “arc”) and, if someone implements sharedOrc, to have it replace regular orc as well?

mm:sharedOrc

In addition to what araq wrote the following scenarios: You get user-input via a GUI widget and want to send that to another thread to do some computation. You are not the code that is generating the data. Therefore, you **can not** isolate what comes out of the widget, for all you know it is s

mm:sharedOrc

Imagine a webservice that reads a `.cfg` file at startup. The configuration is readonly after startup and contains a `JsonNode` part. Can you send an "isolated" configuration to your threads? No, it's shared. You can send a copy, sure. But that is not as convenient and it fails to work when you

mm:sharedOrc

> I know you all like "isolation" but I find it lacking and it's hardly used > out there, afaict. Could you (or someone else) expand on that - and that'd be a great blog post as well - on what / why isolation is lacking ? What problem does --mm:atomicArc / --mm:shared

mm:sharedOrc

"Needed" is a strong word, it is not "needed" but it fills a void. `arc : atomicArc` corresponds to `orc : sharedOrc`. Practically speaking with sharedOrc we could remove the concept of "isolation" and "gc safety" from Nim. I know you all like "isolation" but I find it lacking and it's hardly u

mm:sharedOrc

Can you give the ELI5 of why yet another mm is needed? Would sharedORC be a replacement or an alternative for ORC?

mm:sharedOrc

Ok, and true but =hooks are easy to do. I've been reading the FRC paper. Definitely intriguing.. Although it starts getting pretty complicated. The built-in concurrent read and possibly combining it with `{.cursor.}` seems awesome. Seems like a good fit for a shared-orc design overall.

mm:sharedOrc

Here is the implementation:

mm:sharedOrc

I was curious to find a YouTube talk on the algo. No luck, but this video from a Microsoft researcher mentions Nim!

mm:sharedOrc

`=hooks`on an object that uses `ptr` as a hidden field. However, not even that is required as in test programs and experiments it is usually easy enough to insert the `incRef/decRef` operations yourself.

mm:sharedOrc

> Our team of core developers does not have time to work on any of this, but > the algorithms can be implemented in Nim "userland" code via custom hooks on > top of Nim's unsafe ptr T construct. By that, you mean the `=hooks` on an object like shared pointers or just using raw pointers by thems

mm:sharedOrc

hese memory safe as well 🙂. FRC is patchable with a cycle collector component which would give us `mm:sharedOrc`. For a concurrent cycle collector the best blueprint can still be found in <https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concurrent.pdf> Our team of core developers doe