Good point - I'll play around with that idea. Thanks! On Thu, Nov 10, 2016 at 11:32 AM, Bastian Bloessl <[email protected]> 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. > > 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]> > 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]>> >>> 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]>> 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]> >>> 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 >>> >>> >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
