Repository navigation
Use more precise language in discussion about per-module caches - #70
Conversation
|
Wrong tag. I didn't ask for such features :) |
|
Ugh, sorry! I meant to tag @vfdev-5. |
lysnikolaou
left a comment
lysnikolaou
left a comment
There was a problem hiding this comment.
LGTM!
Unrelated to the changes, but the NumPy PR mentioned below uses PyThread_type_lock, presumably because PyMutex wasn't available at the time. Are there any examples we can link to where PyMutex is used, since that is the best practice now? Or do we want to stick to linking to a PR that uses a heap-allocated lock so that we show how to use the init function?
No we definitely want to use You could link to the NumPy PR where I switched all the locks to |
@vafomin asked me about this. I checked with @colesbury, and I think the updated language is closer to the real guarantees people have.
I'm not sure under what circumstances the per-module locks might be released to avoid deadlocks and whether extension authors should worry about that. It's a bit academic for 3.13, because CPython also re-activates the GIL before importing modules with C extensions, but Sam told me users shouldn't rely on that behavior, so I'm not documenting it.