discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] [GREP] RFC: Remove the msg_queue API from GNU Rad


From: Kevin Reid
Subject: Re: [Discuss-gnuradio] [GREP] RFC: Remove the msg_queue API from GNU Radio
Date: Mon, 2 Jul 2018 07:37:26 -0700

On Fri, Jun 29, 2018 at 7:35 PM Kevin Reid <address@hidden> wrote:
On Fri, Jun 29, 2018 at 6:28 PM Martin Braun <address@hidden> wrote:
I'd like to discuss the removal of the old msg_queue API from GNU Radio. …
I will experiment and see if [Python blocks are] stable when used as a queue replacement. 

I have now finished implementing the changeover but have not tested it much yet. So far things seem OK, but I did find one gotcha.

The obvious straightforward thing to do if you are going to export data to Python (that wants to not be running in the Python block's thread) is to do something like the following. ('reactor' is from Twisted, an event loop framework I am using.)

    def work(self, input_items, output_items):
        items_numpy_array = input_items[0]
        self.reactor.callFromThread(self.callback, items_numpy_array)
        return len(items_numpy_array)

However, this eventually segfaults.

In hindsight, it's obvious that the array ought to be copied, but I didn't think of it the time and I imagine that most beginners trying to do this wouldn't either, and it wasn't in the documentation for Python blocks (which is sketchy, hard to find all of, and lacking in reference-not-tutorial text).

Furthermore, as Python is a memory-safe language, making this mistake ought to produce some kind of appropriate exception rather than an object which could be used to corrupt memory. Such an exception would also be able to help users learn how to fix the problem (if nothing else by giving it a name other than "Segmentation fault").

reply via email to

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