>
> On 03/09/2014 04:58 AM, Activecat wrote:
> > Dear Sir,
> >
> > A python sink block created by gr_modtool has below work() function, it
> > returns the number of input items.
> >
> >     def work(self, input_items, output_items):
> >         in0 = input_items[0]
> >         # <+signal processing here+>
> >         return len(input_items[0])
> >
> > But a c++ sink block created by gr_modtool has the work() function
> > return the number of output items (noutput_items).
> >
> > It sounds contradict. Is there any error happening?
>
>
> On Mon, Mar 10, 2014 at 5:42 PM, Martin Braun <martin.br...@ettus.com>wrote:
> No contradiction. Sinks are always syncs (haha), so noutput_items == the
> number of input items (by definition). The actual output buffer,
> however, is empty -- so we can't use the length of the output buffer to
> tell the scheduler how much we consumed.
>
> In a sync block, there is no argument "ninput_items", so we can't use
> that, either.
>
> M
>


Dear Sir,

If the return value of work() is used to tell the scheduler how much we
have consumed, than it is very clear!

In general_work() of new templates generated by gr_modtool, we always see
this, even for sink blocks:

      // Tell runtime system how many output items we produced.
      return noutput_items;

The comment sounds like the return value of general_work() is to tell the
scheduler how many output items have produced.
If this is true, for sink block, we should actually returned zero because
sink block doesn't produce any output item.

To avoid confusion, and to be more consistent, I suggest to put this
instead into work() of new templates of sink block:

    // Tell runtime system how many input items have been consumed.
    return noutput_items;

Because when I look into sync_block.cc, the return value of work() is
actually used for consume_each(r).

Just a silly suggestion. Thanks.

Regards,
Activecat
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to