On 11/26/2012 10:34 PM, Jose Torres Diaz wrote: > Hi Josh, > > Thanks for your answer. In my BLOCK 2, at the end of the work() function > I'm not returning any parameter at all, so I assume the work() function is > fine and consuming the input in BLOCK 2.
If this is a message port on BLOCK 2, you must check/pop_msg_queue until the queue is exhausted. Thats what I meant to say when I said "consume". Sorry for the confusion. I cant say why E100 might be different. I guess the question is, who is holding all of the messages when it gets "stuck". I wish I had a tool that would tell me about all reference counted objects in a program, the reference count, and the containing object. With a live GUI, etc. Would be so useful :-) -josh > > BLOCK 1 is the only one that has a manager (_mgr), so I believe that all > the blobs are controlled by this BLOCK 1. > > As a last comment, my flowgraph seems to be working OK in my local machine > but not in the E110. I'm not having any memory issue, so I'm quite confuse > why my python file from GRC stops working in an infinite loop. > > Regards and thanks for your help, > > Jose. > > On Tue, Nov 27, 2012 at 4:53 PM, Josh Blum <[email protected]> wrote: > >> >> >> On 11/26/2012 10:11 PM, Jose Torres Diaz wrote: >>> Hi All, >>> >>> I'm still doing some blocks using message passing technique. Now, I'm >>> working with blob passing downstream, however, my code blocks if I run a >>> infinite loop. Before, I had some issues with memory blowing out (using >> PMT >>> dictionaries), but using the pmt manager solves the problem. >>> >>> My code is quite easy, but it does not runs infinitely in E110. >>> >>> BLOCK 1 (Source of Blobs) -------- > BLOCK 2 (Count the number of >> Blobs >>> received) >>> >>> *BLOCK 1 - Source:* >>> This is the source block and it is similar to stream to blob. I'm >> creating >>> a pool of 17 blobs with size 1500 bytes. I added some data into it and >> then >>> posting downstream. >>> >>> *BLOCK 2 - Counter: >>> *It counts the number of blobs received. >>> >>> Running this in the E110 does it only 1000 times (in an infinite loop). I >>> checked the memory usage and it looks stable all the time. I read in >>> https://github.com/guruofquality/grextras/wiki: >>> >>> "Normally, a PMT is created and passed to a downstream consumer. When all >>> downstream consumers delete their references to the PMT, the object is >>> deconstructed and freed back into nothingness. With the PMT manager, >> rather >>> than being deconstructed, the PMT will return to the manager, where the >>> user can reuse the deleted PMT without re-allocation." >>> >>> When it is mention the consumer deleting their reference to the PMT, >> should >>> I do it into my work function in BLOCK 2? or is it done automatically by >>> the manager?. >> >> The PMTs are reference counted. When BLOCK2 work() function consumes the >> input, the scheduler will delete the PMT references in BLOCK2. Then, the >> manager see a reference count of 1, allowing BLOCK1 to use the >> allocation again. So its automatic. >> >> -josh >> >>> >>> Thanks for your help and directions, >>> >>> Regards , >>> >>> Jose. >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
