Re: [Discuss-gnuradio] message buffers

[Josh Blum]

On 06/14/2013 07:41 AM, Yogesh Dahiya wrote:
> Am i getting this right
>  With gr.block, each block has bunch of stream ports (vector<vector>
> ins,vector<vector> outs) and some message port(which we use to specify
> earlier in signature and there numbering use to start after stream ports )
> 
> With gras.block, each block has bunch of ports with bulk_data buffer and
> message queue(which will be posted msg from upstream). So when I am taking
> len(ins[0]) its the length of bulk_data buffer(which buffering stream data
> i guess) so its returning 0.
> 

Yes thats correct. You see, in the old grextras architecture, the
messages support was sort of hacked in. It worked, but it always felt
like it was separate.

With GRAS, a port is more generalized, it can have any type of data.
What type data is available from a port is a question of how the port is
used. I have been calling this "port duck-typing", like the duck-typing
used in some programming languages.

This notion is particularly powerful because you can make blocks which
are totally agnostic about the port's type. For example these
serialization blocks dont care what type a port is, messages, buffers,
tags, you just give them ports and they can serialize/deserialize:

https://github.com/guruofquality/grextras/wiki/Blocks#wiki-de-serialization-io-blocks

> Some more doubts
> 1.when we take length of output buffer m i asking length of output buffer
> available for use (so i don't overwrite previous produced data).

Yes, all of the length is available for you use

> 2. tags are messages(associated with particular bulk_data) so are they
> posted in message queue.(which must be different from actual message queue)

Thats correct. There is actually a separate queue for tags, buffers, and
async messages.

> 3.when we are calling  produce we are basically posting buffer data
> downstream and when we consume we free up the input buffer
> 

Thats correct.

-josh