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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
