I faced with buggy behavior of 'QT GUI Label' in my GRC graph and surprisingly found that GRC generates code making prohibited accesses to qt gui objects from non-gui thread context. I'm not python guru, but I doubt that python is smart enough to detect access to qt objects from different threads and invoke them properly via qt-specific mechanisms. Similar problem observed when widgets slots (executing in main thread context) call variable-changer functions which in turn invoking callbacks of blocks*.
I suppose all blocks in /GUI Widgets/QT category aren't thread-safe and shouldn't be used until this issue has been fixed. * Block's external interfaces(callbacks) are expected to be guarded internally, but I still didn't found no block in gr packages, I working with, which follow this rule. Maybe swig-generated python interface guards all accesses already? If not, GRC user should be so much careful, that one have to check generated code. IMHO, it reduces GRC usefullness greatly... -- View this message in context: http://gnuradio.4.n7.nabble.com/Bug-gr-qtgui-wrong-design-of-variable-type-blocks-for-GRC-category-GUI-Widgets-QT-tp45538.html Sent from the GnuRadio mailing list archive at Nabble.com. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
