Re: [Discuss-gnuradio] About closing flowgraph automatically

Hi,
I would like to thank you for the support,
my issue is entirely solved applying the patch suggested in #797

Cheers :-)

Il 2016-07-24 21:31 Marcus Müller ha scritto:
> 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 [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
>
> _______________________________________________
> 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/ [2]
>
>
>
> Links:
> ------
> [1] http://block.cc
> [2] http://www.ccs-labs.org/%7Ebloessl/
> _______________________________________________
> 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