Re: message buffers

GNU Radio
1

Am i getting this right
With gr.block, each block has bunch of stream ports (vector
ins,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.

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).
2. tags are messages(associated with particular bulk_data) so are they
posted in message queue.(which must be different from actual message
queue)
3.when we are calling produce we are basically posting buffer data
downstream and when we consume we free up the input buffer

2

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
ins,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:

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

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