Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #196408 > unrolled thread

Re: PyGILState_Ensure() deadlocks, why?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PyGILState_Ensure() deadlocks, why? Barry Scott <barry@barrys-emacs.org> - 2024-07-08 09:33 +0100

#196408 — Re: PyGILState_Ensure() deadlocks, why?

> On 7 Jul 2024, at 23:21, Barry via Python-list <python-list@python.org> wrote:
> 
> 
> 
>> On 7 Jul 2024, at 22:09, Tomas Ukkonen via Python-list <python-list@python.org> wrote:
>> 
>>    Py_Initialize();
> 
> You also need to tell python to init threading.

I'm in front of my dev machine now and checking up on threading.

There is no longer any extra init for threads required.

> I think you are missing more python setup code before you can use threads.
> Also i think you need to tell python that your thread wants to call into python.
> But I an not near my dev system to research this for you.

You are right to use PyGILState_Ensure()

But as MRAB says the main thread is holding the GIL.

> 
> I have code to use python from C++ in my pysvn project.
> See the code starting a line 354 in https://sourceforge.net/p/pysvn/code/HEAD/tree/trunk/pysvn/Extension/Source/pysvn.cpp
> That saves the thread state and restores it.

You still might find the classes I wrong to manage GIL acquire and release interesting.
I have the C++ type system enforcing the rules of acquire and release.
As well as RAII ensuring never to leave a block with the GIL in the wrong state.

Barry

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web