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.
Best, Bastian > On 10 Nov 2016, at 17:27, Michael Wentz <[email protected]> wrote: > > Bastian, > > 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. > > -Michael > > On Thu, Nov 10, 2016 at 11:07 AM, Bastian Bloessl <[email protected] > <mailto:[email protected]>> 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 > > 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 > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[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] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[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] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
