Ah, great! This is really the patchset of my dreams :D Thanks! Should've thought of checking out next… or the redmine issue tracker. Must be the heat.
Cheers, Marcus On 24.07.2016 21:18, Bastian Bloessl wrote: > Maybe you want to try the flow graph with the next branch. What you > describe was supposed to be addressed by > > https://github.com/gnuradio/gnuradio/pull/797 > > Best, > Bastian > > > >> On 24 Jul 2016, at 12:39, Marcus Müller <marcus.muel...@ettus.com >> <mailto:marcus.muel...@ettus.com>> wrote: >> >> If I had to pinpoint a culprit, it'd be in >> gnuradio-runtime/lib/block.cc <http://block.cc> >> >> 750 bool >> 751 block::finished() >> 752 { >> 753 if((detail()->ninputs() != 0) || (detail()->noutputs() != 0)) >> 754 return false; >> 755 else >> 756 return d_finished; >> 757 } >> 758 >> >> Meaning that blocks with any stream in- or output can't be finished(), >> and hence, execution will only stop if the blocks are in- or output >> blocked, or the work function explicitely returned WORK_DONE(==-1), >> which probably works quite well for stream-only flowgraphs. >> >> However, that "if" was added but a year ago – and likely for a good >> reason, that I don't see right now. Maybe someone else could have a look >> at this? >> >> Greetings, >> >> Marcus >> >> >> On 24.07.2016 10:55, Marcus Müller wrote: >>> Hi, >>> >>> 'doh. >>> >>> Which leaves one to wonder why the finished state never gets checked. >>> I'll be back after a bit of tracing. >>> >>> Cheers, >>> >>> Marcus >>> >>> >>> On 24.07.2016 08:04, Sylvain Munaut wrote: >>>> Hi, >>>> >>>>> 52 int >>>>> pdu_to_tagged_stream_impl::calculate_output_stream_length(const >>>>> gr_vector_int &) >>>>> 53 { >>>>> 54 if (d_curr_len == 0) { >>>>> 55 /* FIXME: This blocking call is far from ideal but is >>>>> the best we >>>>> 56 * can do at the moment >>>>> 57 */ >>>>> 58 pmt::pmt_t msg(delete_head_blocking(PDU_PORT_ID, 100)); >>>>> 59 if (msg.get() == NULL) { >>>>> 60 return 0; >>>>> 61 } >>>> [snip] >>>> >>>>> Problem is that if we use the non-blocking call here, the >>>>> scheduler would have a chance to process the shutdown signal, but >>>>> it would be constantly asking (spinning) for the output stream length. >>>>> >>>>> You could try out what would happen if we'd added a timeout to the >>>>> blocking cal; that way, you could reduce the spinning, and >>>>> hopefully get the scheduler to check for "done" messages. >>>> There _is_ a timeout ... that "100" in there is the # of millisec to >>>> wait at most. >>>> >>>> >>>> Cheers, >>>> >>>> Sylvain >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Dipl.-Inform. Bastian Bloessl > Distributed Embedded Systems Group > University of Paderborn, Germany > http://www.ccs-labs.org/~bloessl/ <http://www.ccs-labs.org/%7Ebloessl/> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
