> so I'm not generally a programming newbie. I don't think anyone meant to imply that you were a newbie! I apologize if I came off condescending.
I specialized in concurrency and multi-threading at university, and you would be surprised at how many many people would show me code in their hot path that had lots of loops and allocations, and then wonder why their code was still slow even though they _"parallelized"_ it. These were fairly competent programmers otherwise. * * * > For example, is it OK to directly initialize a global variable guarded with a > lock, as I did, or do I have to leave it uninitialized(nil), and get a lock > just to initialize it? That is an interesting question. This is what the nim manual says about it: [https://nim-lang.org/docs/manual.html#guards-and-locks](https://nim-lang.org/docs/manual.html#guards-and-locks) "Top level accesses to gdata are always allowed so that it can be initialized conveniently. It is assumed (but not enforced) that every top level statement is executed before any concurrent action happens." I think that means that the answer is no, you don't have to take a lock to initialize the global variable. YMMV. * * * > I don't use any "refs" in myList(). Perfect. Based on your post I was pretty sure you did the right thing, I just wanted to be clear and cover all the bases. * * * > my assumption is that this code will only be called when initializing the > modules If it's not in the hot path, then it's good enough * * * > I assume the Nim library hashtables only work on local heap Yeah, that's a safe assumption. Nim doesn't have any good lock free or concurrent data structures built in atm. Thankfully Nim is great at interfacing with C lol. * * * > my grep-foo is strong This should hopefully become less of an issue as Nim matures. All aboard the better and moar documentation train!
