[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Josh Blum
Subject: Re: [Discuss-gnuradio] Manager for blob and message passing - Blocking in E110
Date: Mon, 26 Nov 2012 23:04:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

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


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]