Skip to content

Commit 1f0a294

Browse files
encukoucolesbury
andauthored
Add notes on nogil & reinitialization to the Opt-Out section in Module Isolation HOWTO (GH-134141)
Co-authored-by: Sam Gross <[email protected]>
1 parent 7309eb6 commit 1f0a294

File tree

1 file changed

+15
-0
lines changed

1 file changed

+15
-0
lines changed

Doc/howto/isolating-extensions.rst

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -215,21 +215,36 @@ multiple interpreters correctly. If this is not yet the case for your
215215
module, you can explicitly make your module loadable only once per
216216
process. For example::
217217

218+
// A process-wide flag
218219
static int loaded = 0;
219220

221+
// Mutex to provide thread safety (only needed for free-threaded Python)
222+
static PyMutex modinit_mutex = {0};
223+
220224
static int
221225
exec_module(PyObject* module)
222226
{
227+
PyMutex_Lock(&modinit_mutex);
223228
if (loaded) {
229+
PyMutex_Unlock(&modinit_mutex);
224230
PyErr_SetString(PyExc_ImportError,
225231
"cannot load module more than once per process");
226232
return -1;
227233
}
228234
loaded = 1;
235+
PyMutex_Unlock(&modinit_mutex);
229236
// ... rest of initialization
230237
}
231238

232239

240+
If your module's :c:member:`PyModuleDef.m_clear` function is able to prepare
241+
for future re-initialization, it should clear the ``loaded`` flag.
242+
In this case, your module won't support multiple instances existing
243+
*concurrently*, but it will, for example, support being loaded after
244+
Python runtime shutdown (:c:func:`Py_FinalizeEx`) and re-initialization
245+
(:c:func:`Py_Initialize`).
246+
247+
233248
Module State Access from Functions
234249
----------------------------------
235250

0 commit comments

Comments
 (0)