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

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

Best,
Bastian


On 11/10/2016 04:17 PM, Michael Wentz wrote:
> Nathan,
>
> 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):
>
> WARN ASYNCHRONOUS MESSAGE BUFFER OVERFLOWING; DROPPING MESSAGE
>
> 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?
>
> -Michael
>
> On Wed, Nov 9, 2016 at 6:34 PM, West, Nathan
> <natw@ostatemail.okstate.edu <mailto:natw@ostatemail.okstate.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.
>
> Nathan
>
> On Tue, Nov 8, 2016 at 7:27 PM, Michael Wentz <mchlwntz@gmail.com
> <mailto:mchlwntz@gmail.com>> wrote:
>
> Hi,
>
> 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
> message_port_pub()?
>
> 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.
>
> -Michael
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio