Should return the number of input or the number of output?

GNU Radio
1

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?

Regards,
Activecat

2

On 03/09/2014 04:58 AM, Activecat wrote:

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?

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

3 
    return len(input_items[0])

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®.

Just a silly suggestion. Thanks.

Regards,
Activecat

4

Dear Martin,

Apparently the consistency of code across different source files is more
emphasized than its clarity in individual file.
Nevertheless that is clear now, thanks.

Regards,
Activecat

5

OK, I admit I was unclear. Let’s try from scratch:

  • The return function from work() or general_work() is the amount of
    items that were produced.
  • In a sync block, the number of items produced is the number of items
    consumed, so we can use that to save the developer from manually
    consuming(). In other words, in a sync block, the return value is both
    the number of produced and consumed items.
  • Sinks and sources are syncs, therefore the mechanic is always the
    same.
  • Sinks are a special case because they don’t produce anything. However,
    the scheduler knows the block’s io signature, and knows what to do. The
    consume/produce mechanic stays the same, for consistency’s sake, as with
    all other sync blocks.

Hope this clears things up!

M

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, it’s basically the idea of not writing a special case for a
single type of block; and if you are aware that sync blocks are only
subclasses of normal blocks that implement a general_work which
consumes and produces the return value of work, than everything is
clear and readable :slight_smile:
Greetings,
Marcus

On 11.03.2014 01:34, Activecat wrote:

[email protected]wrote:

case because they don’t produce anything. However, the scheduler

If the return value of work() is used to tell the scheduler how
this is true, for sink block, we should actually returned zero

Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP
M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5
8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI
mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco
t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD
rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY=
=4uZc
-----END PGP SIGNATURE-----

7

Yes I agree with you all.
Everything are now clear and readable.
Thank you very much.

Regards,
Activecat