robert wrote:
> Forget all the low level PyGIL... functions.'
Quite the contrary, I would say!
From the Py C API doc, I interpret the PyGIL... functions to be higher
leveled than eg. PyEval_SaveThread(). I've checked into the source of
python to find out what's really going on, and I've learn
Hi!
I think I've found the bug, but I need to confirm this behavior.
My findings is that if you use PyEval_InitThreads(), it is crucial to
release the GIL with PyEval_ReleaseThread() afterwards.
The API docs states that you can release the GIL with
PyEval_ReleaseLock() or PyEval_ReleaseThread(
robert wrote:
> PyGILState_Ensure/Release guarantees to establish the GIL - even if it
> was already held (useful if you deal with complex call
> ordering/dependencies)
I understand this to mean that I dont need to explicitly lock the GIL
(with PyEval_AcquireLock() or PyEval_AcquireThread()).
in python
land at the same time. How can this be done?
Regards,
Svein Seldal
--
http://mail.python.org/mailman/listinfo/python-list
e able to call py from
two independent c-treads!
Regads,
Svein Seldal
--
http://mail.python.org/mailman/listinfo/python-list
e able to call py from
two independent c-treads!
Regads,
Svein Seldal
--
http://mail.python.org/mailman/listinfo/python-list
ges to
deliver to python and thus the py thread must be ready to wait for it.
It will add another thread in the total application (cuz' I cant remove
the extra C thread since it has other important tasks), but I'll give it
a shot at least!
Regards
Svein Seldal
--
http://mail.python.org/
app would then constantly keep this lock when its running
permanently in python.
Basically I would the thread to stop the execution of the main py app,
call the message function deliver(). When the function returns from
python, resume the execution of the main pyapp.
Regards,
Svein Seldal
