Re: [Discuss-gnuradio] Really big items, best practices?

[Michael Dickens]

You can always do what William Plishker (et.al) did for their GPU work -- go to 
< http://gnuradio.org/redmine/projects/gnuradio/wiki/GRConf2011 > and look for 
GPGPU.  They create a separate (but shared among the various process threads), 
non-kernel memory buffer, and then place a pointer (or handle, IDK) to it into 
the GR-buffer.  In this way, they can do processing on any number of items, 
using just a pointer per effective buffer.  Sort of takes the wind out of the 
GR scheduler (since, for all practical purposes you'll probably want do to 
processing on each "item" as it becomes available), but I'm sure you can make 
it work for you.

A historical note for those who care: This style of data propagation and 
processing goes back to (at least) the "olde days" (late 60's / early 70's) 
before SDR (which really originated in the late 80's, and the term was coined 
in the early 90's) -- called "Flow Based Programming" & is still in use today 
in various forms.  You pass tokens (a handle or pointer to data [possibly 
structured as a packet, or just an unstructured frame]) around instead of 
actual data, do processing using those tokens, keep passing them on and/or 
create new ones & discard the old ones.

While I like double-mapped circular buffers because they make edge-condition 
checking simple, they do have their limitations (e.g., can only be so large) -- 
and, having the ability to pass tokens would be quite useful for some types of 
processing.  Seems like there should be a way to have both at the same time, 
using the same underlying buffering concepts.  That way, you could pass actual 
data or just tokens to data, and so long as the receiving block knew what to 
expect it could accommodate.

My US$0.02 - MLD