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
<n...@ostatemail.okstate.edu <mailto:n...@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 <mchlw...@gmail.com
<mailto:mchlw...@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