# Qtgui sink - flakiness at deconstruction time

**URL:** <https://www.ruby-forum.com/t/qtgui-sink-flakiness-at-deconstruction-time/205016>\
**Category:** GNU Radio\
**Created:** [March 27, 2011, 9:25am UTC](https://www.ruby-forum.com/t/qtgui-sink-flakiness-at-deconstruction-time/205016 "2011-03-27T09:25:24Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [March 27, 2011, 9:25am UTC](https://www.ruby-forum.com/t/qtgui-sink-flakiness-at-deconstruction-time/205016/1 "2011-03-27T09:25:24Z")

</div>

I have noticed (either through direct observation, or people’s reports  
to me) that there is some “flakiness” when a flow graph with a qtgui  
sink deconstructs.

(linux) When a flowgraph with a qtgui sink is shutdown, the  
deconstructor for the uhd block does not get called.

(windows) When closing the gui app (sometimes), a windows pops up  
telling me about an error and asking if i want to debug the program.  
(this has also be reproduced with pyqt\_example.py).

I think, that most likely, this is an issue of the qtgui deconstructor  
throwing an exception. But I cannot say for sure.  
[http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9](http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9)

Any suggestions? Anyone else notice this issue?  
-Josh

---

<div class="post-metadata">

**Author:** ![Josh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8797f3/32.png) [@Josh\_B](https://www.ruby-forum.com/u/Josh_B)\
**Post date:** [March 27, 2011, 6:29pm UTC](https://www.ruby-forum.com/t/qtgui-sink-flakiness-at-deconstruction-time/205016/2 "2011-03-27T18:29:16Z")

</div>

On Sun, Mar 27, 2011 at 3:24 AM, Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I think, that most likely, this is an issue of the qtgui deconstructor  
> throwing an exception. But I cannot say for sure.  
> [http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9](http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9)
> 
> Any suggestions? Anyone else notice this issue?  
> -Josh

Yes, I’ve known about this issue for a while but decided to ignore it  
since  
it didn’t seem to be harming anyone (and I had no idea what was causing  
it).  
Since it’s actually starting to affect people, I’ll look into it.

Mike C. has made some big changes to the qtgui framework that I  
have  
yet to find the time to work on merging it. But today seems like a good  
a  
day as any to dive in and start hammering away at these problems.

Also, from another thread, I agree that being able to put multiply  
streams  
into a single scope plot would be really useful. I’ll see what I can do  
about that, too, but that’s going to take some serious surgery since all  
of  
the plots (fft, waterfall, scope, constellation, etc.) are generated at  
the  
same time.

Tom

Tom

---

<div class="post-metadata">

**Author:** ![Josh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8797f3/32.png) [@Josh\_B](https://www.ruby-forum.com/u/Josh_B)\
**Post date:** [March 27, 2011, 6:49pm UTC](https://www.ruby-forum.com/t/qtgui-sink-flakiness-at-deconstruction-time/205016/3 "2011-03-27T18:49:54Z")

</div>

On 03/27/2011 12:28 PM, Tom R. wrote:

> Also, from another thread, I agree that being able to put multiply  
> streams into a single scope plot would be really useful. I’ll see what  
> I can do about that, too, but that’s going to take some serious  
> surgery since all of the plots (fft, waterfall, scope, constellation,  
> etc.) are generated at the same time.

Yeah, the “monolith” approach that’s currently used for the Qt-GUI  
“sink” is a bit awkward for making changes.

My main reason for going down this path is to hopefully avoid some of  
the OpenGL flakiness, the somewhat-better performance, and a  
(subjective) nice “look” to the Qt GUI widgets as compared to the  
WxPython ones.

One of the “hacks” I was thinking of implementing was that if the user  
had selected _only_ the time-domain plot, and the sample-rate was  
“low”, then it would automatically do a strip-chart type display.  
But that was simply a way to avoid changing the API in any way.

Strip-chart is fairly easy to implement as a “preprocessor” for the  
regular time-domain display. Instead of waiting for a buffers-worth of  
samples before calling the time-domain plotter, you shift all the  
samples in the buffer over by one (dropping one off the end), then  
insert the fresh sample at the beginning, then call the plotter. The  
difference is that the plotter gets called on every sample addition,  
instead  
of every DISPLAY-SIZE samples. Obviously, you only want to do this  
for fairly low-rate data, but strip-charts tend to be used for  
low-data-rate stuff, a few samples per second is the usual maximum.

The time-domain plotter already supports separate “pens” for I and Q, so  
adding more pens shouldn’t be that huge a deal at the level  
of the plotter. But the “work” function needs to be made aware of  
potentially more than 1 input data stream.

–  
Marcus L.  
Principal Investigator  
Shirleys Bay Radio Astronomy Consortium

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.