Scheduler and performance counters operate on negative return values from general_work()

[mbr0wn]

The scheduler and performance counters operate on the special, negative return values from general_work(), which is a mathematically incorrect thing to do.

In the case of gr::block::WORK_DONE, this probably doesn't matter.

In the case of gr::block::WORK_CALLED_PRODUCE, values of the performance counters and the block's relative rate will be wrong.

Only 3 blocks return WORK_CALLED_PRODUCE.

Offending lines:

https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L455 :

  int n = m->general_work(noutput_items, d_ninput_items,
                          d_input_items, d_output_items);

ifdef GR_PERFORMANCE_COUNTERS

  if(d_use_pc)
    d->stop_perf_counters(noutput_items, n);

endif /* GR_PERFORMANCE_COUNTERS */

and https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L472

  if(m->update_rate()) {
    rrate = ((double)(m->nitems_written(0)+n)) / ((double)m->nitems_read(0));
    if(rrate > 0)
      m->set_relative_rate(rrate);
  }

and https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/single_threaded_scheduler.cc#L338 :

    d->produce_each(n);     // advance write pointers
    if(n > 0)
      making_progress = true;

The bad case in this, is someone using the single threaded scheduler and the blocks that return WORK_CALLED_PRODUCE, as it will cause buffer::index_add() to do a very wrong write pointer index update.

[marcusmueller]

I hope this is fixed, but I'm not sure.

[marcusmueller]

would be high impact if people were using perf counters. Might be time to supersede them with instrumentation through uprobes, at least on Linux and FreeBSD