Friday, 15 May 2015

python - When is PyEval_InitThreads meant to be called? -



python - When is PyEval_InitThreads meant to be called? -

this question has reply here:

pyeval_initthreads in python 3: how/when phone call it? (the saga continues advertisement nauseum) 5 answers

i'm bit confused when i'm supposed phone call pyeval_initthreads. in general, understand pyeval_initthreads must called whenever non-python thread (i.e. thread spawned within extension module) used.

however, i'm confused if pyeval_initthreads c programs embed python interpreter, or python programs import c-extension modules, or both.

so, if write c extension module internally launch thread, need phone call pyeval_initthreads when initializing module?

also, pyeval_initthreads implicitly acquires global interpreter lock. after calling pyeval_initthreads, presumably gil must released or deadlock ensue. how release lock? after reading documentation, pyeval_releaselock() appears way release gil. however, in practice, if utilize next code in c extension module:

pyeval_initthreads(); pyeval_releaselock();

...then @ runtime python aborts with:

fatal python error: drop_gil: gil not locked

so how release gil after acquiring pyeval_initthreads?

most applications never need know pyeval_initthreads() @ all.

the time should utilize if embedding application or extension module making python c api calls more 1 thread that spawned itself outside of python.

don't phone call pyeval_releaselock() in thread later making python c api calls (unless re-acquire before those). in case should utilize py_begin_allow_threads , py_end_allow_threads macros instead.

python c python-3.x python-c-api python-c-extension

No comments:

Post a Comment