About the work function and memory

Here is a typical work function:
int work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)

output_items seems to be a pointer to a pointer into some pre-allocated
memory. What is stopping me from managing my own memory, pointing the
output items pointer into my memory, and returning an arbitrary
noutput_items?

Is it possible? What are the limitations?

Thanks,
-Josh

On Fri, Feb 26, 2010 at 14:05, Josh B. [email protected] wrote:

Here is a typical work function:
int work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)

output_items seems to be a pointer to a pointer into some pre-allocated
memory. What is stopping me from managing my own memory, pointing the output
items pointer into my memory, and returning an arbitrary noutput_items?

Is it possible? What are the limitations?

Short answer: no.

Longer answer:

The memory pointed to by the output_items vector is a shared buffer
created by the GNU Radio runtime, which implements a thread-safe,
single writer, multi-reader shared ring buffer. The readers in this
case are the downstream blocks inputs that are set up when by calling
‘connect’. See gr_buffer and related classes in the core runtime
directory. When your work function returns the number of items
produced, the runtime adjusts the buffer pointers and “knows” to
signal other connected block threads that input is available.
Likewise, when a work function calls consume, it is telling the
runtime to adjust the input reader pointer, and when all downstream
blocks have moved their reader pointers far enough, the runtime
“knows” to signal upstream block threads that their work function can
be called again. It’s all a highly optimized dance.

Johnathan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs