I've embedded python in a threaded app which contains two threads that may
call into Python. The threads are created via the "C" api. If I can
guarantee (1) that no python API is ever called at the same time from the
two threads, is it necessary to init threads/aquire locks etc
(PyEval_InitThr eads, PyEval_AcquireT hread and friends)?
The reason (2) I ask this is that I'm afraid that the locking takes some
time. Is this concern justified? The docs mention that there is a perfomance
hit when threading is enabled.
/Jesper
(1)
Every call into the python API is guarded with a lock. One reason I believe
this to be more effective than python's internal locking is that nearly all
calls are from the same thread (>99.9%).
(2)
Another reason is that the python source file "thread_nt. h" includes calls
to GetCurrentThrea dId(), which returns Win32's native thread ID.
call into Python. The threads are created via the "C" api. If I can
guarantee (1) that no python API is ever called at the same time from the
two threads, is it necessary to init threads/aquire locks etc
(PyEval_InitThr eads, PyEval_AcquireT hread and friends)?
The reason (2) I ask this is that I'm afraid that the locking takes some
time. Is this concern justified? The docs mention that there is a perfomance
hit when threading is enabled.
/Jesper
(1)
Every call into the python API is guarded with a lock. One reason I believe
this to be more effective than python's internal locking is that nearly all
calls are from the same thread (>99.9%).
(2)
Another reason is that the python source file "thread_nt. h" includes calls
to GetCurrentThrea dId(), which returns Win32's native thread ID.