While working on owlkettle I stumbled over this warning repeatedly. It turns
out owlkettle used `{.locks: 0.}` rather liberally (21 times from what I could
find). A lot of those places are for procs where owlkettle accepts user defined
procs as parameters and this is just to deliberately limit those procs in their
ability to enforce a bit more correctness (aka a "You shouldn't do this here"
kind of thing, I think).
This is there to ensure that no lock is ever acquired in this code, based on: >
Lock level 0 means that no lock is acquired at all. Source:
<https://nim-lang.org/1.6.12/manual_experimental.html#guards-and-locks-lock-levels>
Reading through the same section in the new docs
(<https://nim-lang.org/docs/manual.html#guards-and-locks>) I can't find a
similar way to have such an enforcement mechanism. I asked about this in the
discord and Rika stated that expressing such a thing should no longer be
necessary.
I don't quite see why that would be the case though, since the desire to
enforce that "This code should not access some locked shared mutable memory"
seems to me like it would be something that is relevant regardless of what the
syntax for locks looks like. Or is that something that shouldn't have been used
in the first place?
Note that I myself have very little multi-threading code experience in nim. I'm
aware of how to use locks, but that's about it. So I can't quite figure out the
relevance of guaranteeing no-lock-operations or not.
