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

List:       gnuradio-discuss
Subject:    RE: [Discuss-gnuradio] M-block integration status
From:       Patrik Eliardsson <patrik.eliardsson () foi ! se>
Date:       2010-02-26 10:53:42
Message-ID: 2353D840E7D6904EB79324A7B7EE71F6A5938BD8F8 () EMS ! win ! foi ! se
[Download RAW message or body]

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:eb@comsec.com] 
> Sent: Thursday, January 07, 2010 8:30 PM
> To: Patrik Eliardsson
> Cc: discuss-gnuradio@gnu.org
> 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
> 


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