Hi Andy, 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?
Best regards, Marcus On 06/16/2015 10:25 PM, Andy Walls wrote: > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
