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 On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun <martin.br...@ettus.com>wrote: > 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 > > > On 03/10/2014 02:09 PM, Activecat wrote: > > 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 > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
