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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio