Overriding QThread.run and calling the default implementation

[Barry]

> On 4 Jul 2021, at 20:12, John Ehresman <jpe at wingware.com> wrote:
> 
> This rings a bell —I think this was fixed in Dec 2019, though I don’t remember what version it was fixed in. The problem was how the Python GIL was being handled. I don’t think there was a workaround other than not to override run

In which case once it’s hung connect gdb to the process and do
Gdb> thread apply all bt
you should see that all the threads are waiting on a mutex.

Barry




> John
> 
>> On Jul 3, 2021, at 7:50 PM, Maurizio Berti <maurizio.berti at gmail.com> wrote:
>> 
>> Il giorno dom 4 lug 2021 alle ore 01:36 Jeremy Katz <jkatz at volexity.com> ha scritto:
>> On Fedora 32 using Python 3.8.6, the attached test works for me with
>> PyQt/Qt 5.15.2 and fails to service either event loop with 5.12.10.
>> [...] 
>> The nearly identical C++ version works with both Qt 5.15.3 and 5.12.10.
>> This seems to be an issue within PyQt that has been resolved in newer
>> versions.
>> 
>> Thank you so much for your input.
>> Unfortunately I cannot test it with a newer version (I seriously need to update my base system), but I'm trusting your tests.
>> 
>> It could be interesting to know the whole background about this, though (Phil, if you can, I'd be glad!).
>> My low-level programming knowledge is very limited, so, to my eyes, a simple override of run() that calls the default method shouldn't change anything.
>> But I know that we're talking about a binding (PyQt) *and* a wrapper (QThread), so, many things I'd take for "granted" could happen under the hood.
>> 
>> Thanks again,
>> Maurizio
>> -- 
>> È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi
>> http://www.jidesk.net
>