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?. Thanks for your help and directions, Regards , Jose.
on 2012-11-27 07:12
on 2012-11-27 07:24
On 11/26/2012 10:11 PM, Jose Torres Diaz wrote: > received) > checked the memory usage and it looks stable all the time. I read in > 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
on 2012-11-27 07:35
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. 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 2012-11-27 08:05
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