Forum: GNU Radio Manager for blob and message passing - Blocking in E110

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 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

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 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