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: [email protected] [mailto:[email protected]] On Behalf Of Johnathan Corgan Sent: Saturday, March 31, 2012 1:28 PM To: Tom Rondeau Cc: [email protected] Subject: Re: [Discuss-gnuradio] gr_sync_block question On Sat, Mar 31, 2012 at 07:52, Tom Rondeau <[email protected]> wrote: > On Fri, Mar 30, 2012 at 2:58 PM, Josh Blum <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
