Forum: GNU Radio Bug: gr-qtgui: wrong design of variable-type blocks for GRC (category /GUI Widgets/QT)

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Artem Pisarenko (Guest)
on 2013-12-24 09:40
(Received via mailing list)
I faced with buggy behavior of 'QT GUI Label' in my GRC graph and
surprisingly found that GRC generates code making prohibited accesses to
gui objects from non-gui thread context. I'm not python guru, but I
that python is smart enough to detect access to qt objects from
threads and invoke them properly via qt-specific mechanisms. Similar
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
all accesses already? If not, GRC user should be so much careful, that
have to check generated code. IMHO, it reduces GRC usefullness

View this message in context:
Sent from the GnuRadio mailing list archive at
Artem Pisarenko (Guest)
on 2013-12-26 12:21
(Received via mailing list)
posted partial bugfix to github (pull request #122)

View this message in context:
Sent from the GnuRadio mailing list archive at
Tom Rondeau (Guest)
on 2013-12-30 17:28
(Received via mailing list)
On Thu, Dec 26, 2013 at 6:19 AM, Artem Pisarenko <>
> posted partial bugfix to github (pull request #122)


Thanks. I've got this queued up with a few other patches and am just
waiting on confirmation on one more thing (holiday delays) before it
gets pushed.

This topic is locked and can not be replied to.