RE: [Discuss-gnuradio] M-block integration status

[Patrik Eliardsson]

Dear List,

We are heading to the end of February, what is the status of the message 
passing functionality between blocks? I've been looking around in the 
developers branches but haven't found anything yet...

Can someone update me, please?

Best regards,
Patrik Eliardsson

 

> -----Original Message-----
> From: Eric Blossom [mailto:address@hidden 
> Sent: Thursday, January 07, 2010 8:30 PM
> To: Patrik Eliardsson
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] M-block integration status
> 
> On Mon, Jan 04, 2010 at 03:49:38PM +0100, Patrik Eliardsson wrote:
> > Hi Folks,
> 
> > Now when the VRT implementation seems to be almost finished,
> 
> We're getting there!
> 
> > what is the status of the integration of m-block 
> capabilities into the 
> > gnu-radio? The functionalities described here 
> > 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00319.ht
> > ml are just what we are looking for. However, if we don't 
> want to wait 
> > too long, can this be achieved with m-blocks at the moment? What 
> > functionality is missing in the m-blocks? Or has anyone 
> solved this in 
> > another way?
> 
> m-blocks are deprecated, and no further development will be 
> done on them.
> 
> We have a two pronged approach to achieving similar (or 
> related) functionality.  In no particular order they are:
> 
> (1) Designing and implementing a mechanism whereby blocks can 
> embed isochronous metadata in a data stream, tied to specific 
> sample indicies.  The idea is that blocks can check or set 
> key/value pairs over a range of sample indices.  We expect 
> the metadata for streams that originate from a VRT source to 
> contain the VRT Timestamp at the appropriate sample index.  
> The GR runtime will be extended such that existing blocks, 
> which are naive about this feature, will transparently 
> forward metadata from their inputs to their outputs.
> 
> (2) Implement per-block message queues to asynchronously 
> receive messages containing arbitrarily-typed payloads from 
> other blocks, and process them.  (The first phase of this is 
> complete, but we haven't advertised the feature since we're 
> lacking support in hier_blocks, a high-level way to wire 
> everything together, and are missing documentation and 
> examples).  As part of this, GR block "work" methods can send 
> asynchronous messages.  When a block receives a message, its 
> handle_msg(pmt::pmt_t msg) method is called.  The runtime 
> ensures that handle_msg is never called while the block is in 
> "work" and vice-versa.  That is, the runtime handles 
> everything related to ensuring that this feature works 
> reliably in a multi-threaded environment.
> 
> Both of these are on my "short-list" of work to get done.  I 
> expect that both will be complete by the end of February.
> 
> I want to make a couple of additional observations about 
> async message passing (2).  Async message passing allows for 
> the creation of blocks which:
> 
>   * Have only streaming input and/or outputs (like today)
>   * Have only async message passing (no streaming i/o)
>   * Have both streaming input and/or outputs and have async 
> message passing
> 
> This gives us the possibility of easily bridging between the 
> dataflow and message passing enviroments.  We expect that 
> many "MAC-like"
> features will be implemented using async message passing, 
> while some PHY layer stuff will continue to be implemented 
> using the data flow paradigm.
> 
> Adding a msg_handler to existing blocks allows block 
> parameters to be tweaked at runtime without fear of thread 
> safety problems. We've been kicking around some ideas for a 
> "middle layer" that supports getting and setting arbitrary 
> attributes, in such a way that adding them to a block is as 
> simple as filling in a small table.
> 
> > Regards,
> > Patrik Eliardsson
> 
> Thanks for your question, and if you've got more, please ask away!
> 
> Eric
>