[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] What conditions will cause block destructor to be

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] What conditions will cause block destructor to be skipped?
Date: Sat, 12 Oct 2013 10:59:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

Hi Tim,

you're entering a minefield there...
Since you've built your flowgraph using GRC, you have a python-constructed 
flowgraph. That's why things start to get confusing for the c++ developer.
First of all, destructors of python objects are called whenever the python 
runtime feels like it - this often happens when you do something like
object_name = None
but it doesn't necessarily has to happen right away. The Garbage Collector can 
choose when to do it, and sometimes, it decides not to do it at all - if your 
program terminates first, this might be the case. Furthermore, if it decides 
that at the end of runtime, it should destruct its output stream file handles 
before destructing your block, your printf output might be lost.
Then: You have a C++ object wrapped by SWIG. So, what you're seeing in Python 
is not actually an instance of your block, it is a SWIG object holding a 
reference to such an instance. Usually, when that Swig Object's python 
destructor is called, it should delete the block instance, too, but then again, 
if I knew what really happens inside SWIG, I'd feel a lot wiser.
Lastly: Destructors doing actual work is a tricky thing. Mostly, because, what does the 
runtime (both, c++ or python) do when a destructor throws an exception? In that case, 
should the runtime ignore it and just think "meh, whatever, it's dead anyway" 
or should it cause the program to exit with a failure state? And: what if a C++ 
destructor fails that got called by the python garbage collector? That shouldn't crash 
the global python interpreter, should it?

So these are the pitfalls I could think of. Maybe the situation is a lot 
easier, though :) Post some code, maybe a github gist or a pastebin!

Happy Hacking,

On 10/12/2013 12:24 AM, Monahan-Mitchell, Tim wrote:
Rarely, I'm seeing evidence that my custom source block destructor is not being 

My flowgraph was built with "No GUI" and "Prompt for Exit" options (GR 3.7.1+)

The condition is that my source block's work function has moved to a state 
returning WORK_DONE, and will stay in that state.

When I press Enter to end the flowgraph, I sometimes don't see the usual ending 
printf() outputs. Fortunately, it does not happen often.

This article cites such a case: 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00055.html, but 
my flowgraph only has my custom source block and a File Sink block.


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]