> I have found that ORC + multithreading do not mix in the way one might expect > imo. The mental model from Java, Go, C# etc is not transferable for those > that expect it. Took me a long time to really internalize that for some > reason when coming from that background myself.
I didn't do a lot of explicit multithreading before Nim, other than in simple networking applications with blocking I/O, mainly in Java. The rest of what I did was using the actor model and doing message passing, bypassing explicit management of threading entirely. The situation I find myself in now is that while previously in other languages I didn't touch shared memory often, in Nim I now have to take extreme caution when doing so in the rare cases that I do use it. As Nim doesn't have any native non-blocking message passing scheme for inter-thread communication, I've been having to explore ways to do that, and it's proven a bit difficult with ORC. In any case, I'm concerned about the day when ORC becomes the default memory management strategy, because I don't think a lot of people are ready for it. I'm lucky enough to have been using it for a while now and know what to avoid, but compiling other programs with it right now tend to produce crashes. I'm also not particularly trusting of the cycle collector, as I've gotten incredibly inconsistent memory usage when using it with asyncdispatch and asyncnet, often seeing what appear to be classic memory leaks. That may be a stdlib problem, but in theory, there shouldn't be any leaks at all under ORC, no matter how lazy you are with heap allocations and cyclical objects. I haven't done much thorough testing with Chronos, but I tend to think this is largely a cycle collector issue where things are falling through the cracks.
