discuss-gnuradio
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]