On Tue, 2015-06-16 at 12:27 -0700, Johnathan Corgan wrote: > On Tue, Jun 16, 2015 at 10:16 AM, Nick Foster <bistrom...@gmail.com> > wrote: > > Issue #1 is likely the problem. Thanks for pointing that out, > Andy! The other two issues should be pretty miniscule in > overhead, but are probably good ideas nonetheless. The block > was written for clarity rather than for speed, but even so it > shouldn't be particularly heavy-duty.
> In the future, we plan to allow designating a non-empty message queue > as a prior condition to be satisfied before the scheduler calls > work(), thus it will won't ever be necessary to block inside work > directly on the queue itself. This is a common issue with source > blocks that rely on input message ports for content. Hi John, That will help for blocks which can somehow guarantee that every incoming message will never generate more than noutput_items in every call to work. Otherwise the block is going to have to save away the residual output items, to be output in a later call to work(). There is no need to block on message input to output those residual output items. I.e. in a call to work(): 0. output any residual items saved from last call to work() 1. grab message off queue (making a decision to block or not as appropriate) 2. generate items, which may number more than noutput_items 3. store any residual items for output for next call to work() 4. return number of items generated up to noutput_items The hdlc_framer looks like it has this notion of a residual in d_leftovers. Although different from GnuRadio internal messaging, some internal fixes I made to the gr-zeromq sub_source_impl.*, to work reliably and at high throughput, also needed to deal with residual parts of messages that could not be sent out in the current call to work() and had to deal with context depending blocking when checking for messages. (The current sub_source_impl.* on the master branch discards the items in incoming ZeroMQ messages that are beyond noutput_items - not a nice thing to do.) My $0.02 Regards, Andy _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
