Hi Activecat, it's a sink. As Martin said, keep it a sync block. Overriding forecast doesn't even make sense; why should the scheduler ask the block "I'd like to have 2000 output items from you, how much input do you need" if it's guaranteed to never produce output.
Maybe I'm getting something wrong, so why would you want to costumize the forecast function? Greetings, Marcus On Sun, May 4, 2014 at 3:49 AM, Activecat <active...@gmail.com> wrote: > Part of this question has been partially discussed, as below. > > 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*. >> > > > Says, now I need to create a sink block, and I need to highly customize > its built-in forecast() function. > Hence I have two choices:- > (i). Create this as a sink block, then explicitly overwrite its > forecast() function in the body of the custom block. > (ii). Create this as a general block. > > Question 1: Will option (i) above work? > > Question 2: If a sink block is implemented as a general block, does it > still need to return noutput_items, or just return 0, or doesn't matter at > all ? (I guess it should return 0 because the sink block doesn't produce > any output) > > > >> - 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 >> >> > > > _______________________________________________ > 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
