On Wed, 2015-06-17 at 12:01 -0400, [email protected] wrote: > Message: 11 > Date: Tue, 16 Jun 2015 16:04:54 -0700 > From: Johnathan Corgan <[email protected]> > To: Marcus M?ller <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Discuss-gnuradio] CPU usage when hdlc framer is used > Message-ID: > <CALOxbZvhVvSDEKPN==y_zjS45xD8+qbRcYGSueOAAF8Jv=x...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Jun 16, 2015 at 1:32 PM, Marcus M?ller <[email protected]> > wrote: > > > > if I understand you correctly, you think the situation calls for > > something like a "wait for message flag" that a block would need to set > > every work call? > > > Actually, this is the idea--that, *when needed*, make a call to the > scheduler just before ending work, that says, in in effect--don't call me > again until input message port X is not empty. > > Otherwise, call me again whenever you otherwise would, which, for a source > block, is when there is room in the output buffer (subject to other > constraints.) > > This would allow work() to be invoked one more times as needed, to exhaust > any pending data that might exceed noutput_items in a given call, yet then > finally wait on a message for more content. > > The key point would be to not block in work, which prevents the scheduler > from that block from processing any other events, but instead allow the > scheduler itself to do so.
Hi John, Yes, that seems right. The block needs to continually keep the gnuradio infrastructure informed about when to wait for a message or not, before calling work(). The infrastructure can't possibly know otherwise. Regards, Andy _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
