[Top][All Lists]

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

Re: [Discuss-gnuradio] Flow control with message ports

From: Michael Wentz
Subject: Re: [Discuss-gnuradio] Flow control with message ports
Date: Thu, 10 Nov 2016 11:34:07 -0500

Good point - I'll play around with that idea. Thanks!

On Thu, Nov 10, 2016 at 11:32 AM, Bastian Bloessl <address@hidden> wrote:
OK that makes sense, but note that the approach can easily be extended to having always N messages in the queue (just create N initial messages). So it would not necessarily introduce a lot of delay.


On 10 Nov 2016, at 17:27, Michael Wentz <address@hidden> wrote:


Thanks for the suggestion, it's a good idea but may not meet my requirements (my messages have timestamps, some spaced very closely together, and I'd rather have those loaded up in the queue as soon as possible rather than have to go through a handshaking process).

I ended up moving my file parsing into my sync_block and doing away with the message port since I couldn't figure out a way to have a blocking publish to the queue without modifying GR. This works but in the future I also wanted to distribute that information to other blocks, and with the current approach I'll have to duplicate the file parsing in all of those too.


On Thu, Nov 10, 2016 at 11:07 AM, Bastian Bloessl <address@hidden> wrote:
I don't know a good solution, but when I had a similar problem, I ended up with:

- the file parser creates an initial message
- the sync block sends a message back to the file parser when it converted the message into stream domain
- this message triggers sending the next (actual) message in the parser block


On 11/10/2016 04:17 PM, Michael Wentz wrote:

I don't have any other queue in my block - it's just the one associated
with the message port. The following starts printing once I send too
many messages (before the block downstream has started processing them):


Looking at tpb_thread_body.cc, it seems that maybe I'm in a special case
given I don't have a handler for the block receiving the messages (it
decides when to check the queue on its own). In that case it looks like
the queue is limited to 100 messages?


On Wed, Nov 9, 2016 at 6:34 PM, West, Nathan
<address@hidden <mailto:address@hiddene.edu>> wrote:

    I'm not sure I understand. There was once a proof of concept
    flowgraph called pmt_smasher that would effectively keep publishing
    messages and the queue grows without bounds which was generally
    considered a low-priority issue (having no back pressure/flow
    control on message ports).

    You're describing different behavior than I understand the message
    ports to have. Is the queue that's overflowing some custom queue in
    your block that you dump new messages on to? If so just make that
    queue grow as more messages come in.


    On Tue, Nov 8, 2016 at 7:27 PM, Michael Wentz <address@hidden
    <mailto:address@hidden>> wrote:


        I've made a block in Python that has one message port out and no
        other ports. What the block does is simple: read from a file,
        parse data into a dict, convert to a PMT, and publish as a
        message. The port is connected to a sync_block that is acting on
        these messages when it deems fit. My desired behavior is for the
        publisher to fill up the queue as fast as possible and block if
        the queue is full (waiting for room to open up). What I've
        observed is that the queue will instead overflow and messages
        will be dropped. Is there any way to have a blocking call to

        Looking through the code I do see a method in basic_block to get
        the number of messages in the queue, which I could use to decide
        to publish a message or not - but this isn't brought out in the
        SWIG interface. Is there a reason why? If not, I was thinking
        about re-defining the SWIG interface for basic_block in my OOT
        with additional methods, but was wondering if that would create
        conflicts/weird issues.

        Any other ideas for how to do this would be appreciated. I
        realize I could parse the file in my sync_block, but that's my
        last resort here.


        Discuss-gnuradio mailing list
        address@hidden <mailto:address@hiddenrg>

Discuss-gnuradio mailing list

reply via email to

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