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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
