Announcement (2017-05-07): www.ruby-forum.com is now read-only since I
unfortunately do not have the time to support and maintain the forum any
more. Please see rubyonrails.org/community and ruby-lang.org/en/community
for other Rails- und Ruby-related community platforms.

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

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

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

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

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