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.