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 <address@hidden>
wrote:
If I had to pinpoint a culprit, it'd be in
gnuradio-runtime/lib/block.cc [1]
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