Message passing(connect) in C++

Hi all,
I have another question. How can I connect the input and output port of
different blocks,from inside a C++ block? In the documentation I’ve only
seen the msg_connect() for python


Hi Marco,

The top_block class has a member named: connect. You can use it in the
main() to connect different blocks. However, if you want to dis/connect
blocks within C++ blocks, you must pass top_block pointer to the class
some fashion. Once I did and I got errors because I didn’t have accessed
the “connect” from within the block.

I prefer to change your topology to refuse the need you’ve mentioned.
Otherwise describe your problem with more details.


On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero
[email protected]

[email protected]
Discuss-gnuradio Info Page

Department of Electrical Engineering
Aboureyhan Building
Amirkabir University Of Technology
Tel: +98 (919) 158-7730

excuse me,

I’m seeing the new API 3.7.7 of GNURadio which is changed. The “connect”
a member of gr::flowgraph which connects both blocks’ ports and message


On Thu, Apr 30, 2015 at 4:15 PM, Mostafa A.
[email protected]

I have another question. How can I connect the input and output port of

Tel: +98 (919) 158-7730

Department of Electrical Engineering
Aboureyhan Building
Amirkabir University Of Technology
Tel: +98 (919) 158-7730

I want to exchange data between adjacent blocks which are already
through the GUI, without ask to the user to write additional code.
So my approach would be: the upper block send down its name(through
and the lower block configure the communication, so I thought to take
advantage from message passing.
If I won’t be able to use this approach, I will use some memory shared

Just a question,in order to use the gr::flowgraph:connect(),I need to
the object flowgraph from the XML file situated in GRC,isn’t it?

Il giorno gio 30 apr 2015 alle ore 13:48 Mostafa A. <
[email protected]> ha scritto:

Marcus, thank you very much for your deep answer.
Your proposal about the usage of
your_block::detail()->input(0)->buffer()->link seem very interesting, so
shoulld evaluate if use this mechanism or only some memory allocation
created with malloc.

I’d prefer to simplify the life of user as much as possible…I’ll put my
blocks on a repository, hoping that some user will use these blocks.

Your proposal of a hierarcly approach is interesting,but in my case
be more problematic: user can have a DAG or graph flowgraph,and the
of the next block,performed by each involved block,could add some
complexity, considering that I need to open connection only between
adjacent blocks.

I summarize what I’m doing: as thesis ,I’m trying to make a partial
over CUDA…so I’m re-implementing blocks with CUDA. Each block allocate
circular buffer of device pages,passing these pointer with other info to
the next block(using a tag with a pointer to host memory). Now I want to
establish an initial handshake, because the following block could have
preferences(usually not mandatory,because often the first step of a
is to copy data from global to shared memory,allowing some degree of
freedom) about incoming data(e.g. min-max dimension of each
page,min_multiple for input data of FFT,…). Each block receive data
throught device memory,elaborate all data and return a single useless
tap,in order to wake up other blocks…at the end of chain,data will be
copied into host memory.


Hi Marco,

ok, I think it’s best if I describe a bit of what happens behind the
GRC is really just a graphical generator for python code. As soon as you
hit the “generate” button (or the run button, where generating is done
inherently), python code is written that has no connection, knowledge or
dependency to the XML that was used to generate it.

From a user-friendliness point of view, I can fully understand your
approach to take the burden to explicitly connect up- and downstream
blocks off your user’s shoulders. You can actually hack together
something like that even without the use of tags, by just implementing a
start() method in your block. You’d pass a top_block::sptr to the
constructor, and then, in your_block::start() get the upstream block
doing your_block::detail()->input(0)->buffer()->link(), check that
block for being your other block type, and if not, continue the search
through the flow graph in the same matter. After you’ve found your other
block, ou use your stored top_block::sptr to ->msg_connect(other_block,

However: that breaks a lot of assumptions I would made when looking at a
flow graph, mainly the assumption that downstream blocks don’t invisibly
influence behaviour of upstream blocks. Honestly, letting your user
connect your two blocks with msg_connect doesn’t sound like a bad idea
in the long run.

Or you come up with a hier-block-based approach: – are sample streams,

message passing

            |               your_hier_block                |
            |                                              |
            |       .------------------------.             |
            |       |  your_upstream_block   |             |
            |       |------------------------|             |
            |   --->|                        |---------------->to 

user blocks
| | | | |
| | ‘------------------------’ |
--------------->|— ^ |
| # |
| # |
| .------------------------. |
| | your_downstream_block | |
| |------------------------| |
| | |<----------------from
user blocks
| | | |
| ‘------------------------’ |
| | |
further processing

Best regards,