Thanks for clearing that up. That's what I surmised after poking around gr_block_executor; the problem turned out to be a mistake in the work function of a data source I put together.
-----Original Message----- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On Behalf Of Johnathan Corgan Sent: Saturday, March 31, 2012 1:28 PM To: Tom Rondeau Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gr_sync_block question On Sat, Mar 31, 2012 at 07:52, Tom Rondeau <t...@trondeau.com> wrote: > On Fri, Mar 30, 2012 at 2:58 PM, Josh Blum <j...@joshknows.com> wrote: >> On 03/30/2012 11:23 AM, Nowlan, Sean wrote: >>> Do objects that extend gr_sync_block *require* that their work >>> function *always* returns as many items as the scheduler asked in >>> noutput_items, except for the case when a block may be completely >>> finished producing items? >> >> Returning 0 or -1 will tell the block executor code to stop. >> >> -Josh > > Just to clarify, a block can legitimately return 0; it just means that > it didn't produce any output, but it will try again. To clarify even further--a *source* block that returns 0 samples will be treated as done, for other blocks it is ok. Johnathan _______________________________________________ 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
