Forum: GNU Radio Should return the number of input or the number of output?

739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-03-09 05:00
(Received via mailing list)
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
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-03-10 10:43
(Received via mailing list)
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
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-03-10 14:10
(Received via mailing list)
> >         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(r).

Just a silly suggestion. Thanks.

Regards,
Activecat
B4ffbc711addde4c649b1ed526df6157?d=identicon&s=25 Martin Braun (Guest)
on 2014-03-10 14:20
(Received via mailing list)
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
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-03-11 01:36
(Received via mailing list)
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
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 Marcus Müller (Guest)
on 2014-03-11 10:09
(Received via mailing list)
-----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 :)
Greetings,
Marcus

On 11.03.2014 01:34, Activecat wrote:
> <martin.braun@ettus.com>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
>>>
>>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----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-----
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-03-11 10:17
(Received via mailing list)
Yes I agree with you all.
Everything are now clear and readable.
Thank you very much.

Regards,
Activecat
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.