Re: [Discuss-gnuradio] Manager for blob and message passing - Blocking in E110

[Josh Blum]

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 <address@hidden> 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
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>