Svein Seldal wrote:
> A real beauty about the PyGILState_Ensure() is the fact that if it's
> called from a thread that is (yet) unknown to python, it will actually
> create the thread state object for you (with PyThreadState_New) and
> acquire the lock. Hence, I dont have to worry about the pro
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
Svein Seldal wrote:
You seem to use the functions in very rude manner - wanting to force the GIL
around at lowest level.
Better forget the word GIL and think about acquiring and releasing Threads.
For each thread wanting to execute Python stuff there has to be a thread state
(ts). And then you
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(
"Svein Seldal" <"svein at seldal dot com">wrote:
8<---
> I am dependent upon the ability to have to threads executing in python
> land at the same time. How can this be done?
call time.sleep(0.001) in each, as well as the main thread, to politely giv
Svein Seldal wrote:
> 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(
Svein Seldal wrote:
> I'm unable to get access to python as long as another python call is
> executing. The PyEval_AcquireThread() call blocks until the first call
> returns. I was hoping that the python system itself would release the
> GIL after some execution, but it itsnt.
>
> I am dependen
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()).
Svein Seldal wrote:
> Hi
>
> A couple of mulithreaded C API python questions:
>
> I) The PyGILState_Ensure() simply ensures python api call ability, it
> doesnt actually lock the GIL, right?
>
> PyGILState_STATE gstate;
> gstate = PyGILState_Ensure();
>
> II) Am I required to lock the
Hi
A couple of mulithreaded C API python questions:
I) The PyGILState_Ensure() simply ensures python api call ability, it
doesnt actually lock the GIL, right?
PyGILState_STATE gstate;
gstate = PyGILState_Ensure();
II) Am I required to lock the GIL prior to running any python fu
10 matches
Mail list logo
