Re: [Discuss-gnuradio] About closing flowgraph automatically

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.mueller@ettus.com> wrote:

If I had to pinpoint a culprit, it'd be in gnuradio-runtime/lib/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
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/