Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Sylvain Munaut]

> 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