[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template
From: |
Tom Rondeau |
Subject: |
Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template |
Date: |
Thu, 26 Sep 2013 10:06:18 -0400 |
On Wed, Sep 25, 2013 at 6:10 PM, Sylvain Munaut <address@hidden> wrote:
>> I also tried creating the QWidget subclass separately, like it's done
>> in the qtgui elements but I also have a problem on destruction because
>> there is a tight link between the two (exchanging a lot of data ..)
>> and they're destroyed independently by two completely different path
>> ...
>
> Ah, at least I found how to deal with that.
>
> The default top level generated by GRC does something like this :
>
> qapp = Qt.QApplication(sys.argv)
> tb = top_block()
> tb.start()
> tb.show()
> qapp.exec_()
> tb.stop()
> tb = None
>
> Now the problem is that the Qt stuff will start to get cleaned up
> before all the block stop() methods have run and so some processing
> might still be going on while some Qt element get destroyed and then
> all hell breaks loose ( abort / segfaults / exceptions / ... )
>
> Adding a tb.wait() right after the tb.stop() seems to fix the problem.
> But it might even be better to register an "aboutToQuit()" signal
> handler and issue the stop() & wait() to the flowgraph before any of
> the Qt app cleanup even begins.
> And this seems to fit the recommended usage
> http://doc.qt.digia.com/4.7/qcoreapplication.html#aboutToQuit
>
> And you get something like this :
>
> qapp = Qt.QApplication(sys.argv)
> tb = top_block()
> tb.start()
> tb.show()
> def quitting():
> tb.stop()
> tb.wait()
> qapp.connect(qapp, SIGNAL("aboutToQuit()"), quitting)
> qapp.exec_()
>
> Where the order of destruction makes more sense. You end up having :
>
> - All stop() method called and wait for completion of all
> - Destruction of all QWidgets by Qt
> - Destruction of all blocks themselves
>
> This at least gives the opportunity to blocks that create some Qt
> widget to _know_ that they should stop accessing them because they
> might not be there anymore ... (in my case I start/stop a worker
> thread in the gr::sync_block start/stop methods and that thread
> accesses the QWidget create by the block)
>
>
> Cheers,
>
> Sylvain
Excellent, Sylvain!
Yes, the destruction of objects with QT being "good" and doing its own
garbage collection was a hassle for me at the beginning, too. This
looks like a nice solution, especially if it solves your issues.
Once you've settled everything and have your OOT module working and
tested, can you send us a couple of patches for these things? Or you
and I can work offline to make sure things are fixed correctly.
Thanks!
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13