[PyQt] Bug Report: QThreadPool doesn't take the ownership of QRunnable

[Hans-Peter Jansen]

Dear Phil,

On Freitag, 21. März 2014 17:33:42 Phil Thompson wrote:
> On 21-03-2014 9:43 am, Riccardo Ferrazzo wrote:
> > Hi,
> > In PyQt5 i'm having problems due to deleted objects inside the
> > QThreadPool.
> > I've created a simple example to prove the existence of the problem:
> > 
> > from PyQt5.QtCore import *
> > from time import sleep
> > 
> > class Test(QRunnable):
> >     def __init__(self):
> >         QRunnable.__init__(self)
> >     
> >     def run(self):
> >         sleep(10)
> >         print(self, "Awake!")
> >     
> >     def __del__(self):
> >         print(self, "Deleted")
> > 
> > def run_thread():
> >     t = Test()
> >     QThreadPool.globalInstance().start(t)
> > 
> > if __name__ == "__main__":
> >     for i in range(10):
> >         run_thread()
> >     
> >     sleep(20)
> > 
> > It prints out:
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fcc8>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Awake!')
> > (<__main__.Test object at 0x7feb8499fc30>, 'Deleted')
> > (<__main__.Test object at 0x7feb8499fcc8>, 'Awake!')
> > (<__main__.Test object at 0x7feb8499fcc8>, 'Deleted')
> 
> The main problem should be fixed in tonight's snapshot. You can work
> around it by keeping an explicit reference to the global QThreadPool.
> 
> However there still seems to be a problem. My system hangs when the
> thread pool is exhausted - it seems unable to re-use a thread. However
> putting a sleep() (for 4 seconds in my case) after the call to start()
> makes everything work. Using a shorter delay allows about 7 runs before
> hanging.

Due to considerable differences in threading implementations of all supported 
OS of Qt, it would be nice to refer to the variant, you're testing with. 
Especially behavior differences of windows and non-windows platforms is 
interesting.

While one can safely imply current versions of Qt5, sip and PyQt5 in your case 
;), for later reference, it would be kind to mention versions of main actors 
here..

Cheers,
Pete