[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
From:       Tom Rondeau <trondeau1122 () gmail ! com>
Date:       2011-09-27 15:19:36
Message-ID: CANc0s2Mre07NXgsx38a6RUZLZctduY1KPBpLHfwF8mRPM3DbdA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Sep 27, 2011 at 11:14 AM, Josh Blum <josh@joshknows.com> wrote:

>
> >>
> >> I want to support proper message passing. I noticed that I can register
> >> a message handler to receive messages. Can you point me to how messages
> >> are produced?
> >>
> >
> > So you basically need to create a callback function and set it as the
> > message handler. So you call:
> >
> >      template <typename T> void set_msg_handler(T msg_handler){
> >       d_msg_handler = msg_handler_t(msg_handler);
> >     }
> >
> > Where d_msg_handler is of type:
> >
> >     typedef boost::function<void(pmt::pmt_t)> msg_handler_t;
> >
> > You then use gruel::send (in msg_passing.h) to a block that has a message
> > acceptor handler defined (or not; if there is no handler, nothing
> happens).
> > You can see gnuradio-core/src/lib/runtime/qa_set_msg_handler.cc  for an
> > example of this.
> >
>
> I did my own digging last night, and found that gr_block inherits
> gr_basic_block inherits gr_msg_accepter which has post(). So the
> gruel::send is just a function to call this post() method.
>
> So, there is nothing here that really deals with message propagation.
> Message sending exists at the block level but not at the flow graph
> level. Or am I am misunderstanding.
>
> -Josh
>

You are correct, sir.

The messages are handled, on the other hand, in the flowgraph. You can find
it in gr_block_executor, if you are so inclined. But that's purposefully
behind the scenes, so you shouldn't have to worry about that at all.

Tom

[Attachment #3 (text/html)]

<div class="gmail_quote">On Tue, Sep 27, 2011 at 11:14 AM, Josh Blum <span \
dir="ltr">&lt;<a href="mailto:josh@joshknows.com">josh@joshknows.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">

<div class="im"><br>
&gt;&gt;<br>
&gt;&gt; I want to support proper message passing. I noticed that I can register<br>
&gt;&gt; a message handler to receive messages. Can you point me to how messages<br>
&gt;&gt; are produced?<br>
&gt;&gt;<br>
&gt;<br>
&gt; So you basically need to create a callback function and set it as the<br>
&gt; message handler. So you call:<br>
&gt;<br>
&gt;      template &lt;typename T&gt; void set_msg_handler(T msg_handler){<br>
&gt;       d_msg_handler = msg_handler_t(msg_handler);<br>
&gt;     }<br>
&gt;<br>
&gt; Where d_msg_handler is of type:<br>
&gt;<br>
&gt;     typedef boost::function&lt;void(pmt::pmt_t)&gt; msg_handler_t;<br>
&gt;<br>
&gt; You then use gruel::send (in msg_passing.h) to a block that has a message<br>
&gt; acceptor handler defined (or not; if there is no handler, nothing happens).<br>
&gt; You can see gnuradio-core/src/lib/runtime/qa_set_msg_handler.cc  for an<br>
&gt; example of this.<br>
&gt;<br>
<br>
</div>I did my own digging last night, and found that gr_block inherits<br>
gr_basic_block inherits gr_msg_accepter which has post(). So the<br>
gruel::send is just a function to call this post() method.<br>
<br>
So, there is nothing here that really deals with message propagation.<br>
Message sending exists at the block level but not at the flow graph<br>
level. Or am I am misunderstanding.<br>
<font color="#888888"><br>
-Josh<br>
</font></blockquote></div><br><div>You are correct, sir.</div><div><br></div><div>The \
messages are handled, on the other hand, in the flowgraph. You can find it in \
gr_block_executor, if you are so inclined. But that&#39;s purposefully behind the \
scenes, so you shouldn&#39;t have to worry about that at all.</div>

<div><br></div><div>Tom</div><div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic