Re: [Discuss-gnuradio] About closing flowgraph automatically

[Piotr Krysik]

Hi Marcus,

>Debugging your flowgraphs on a C++ and threat level when they ought to
>be exiting would be pretty interesting!

An example of my flowgraph where I used PDU to tagged stream convertion
is this:
https://github.com/ptrkrysik/examples/blob/master/voice_decoding_in_grc/tch_f_reception.grc

Messages with GSM coded voice frames are turned into stream so they can
be decoded with GSM full-rate audio decoder and played in gnuradio audio
sink.

This might be too big flow-graph for the purpose of debugging, so I
prepared minimal working example presenting the problem. The flowgraph
and its input file are attached to this post. If you want to run it in
GRC you will have to correct the File option of the file meta source to
absolute path to the tagged_stream file. I don't know how to do relative
paths in GRC yet.

Best Regards,
Piotr


W dniu 23.07.2016 o 11:55, Marcus Müller pisze:
> Hi Piotr,
>
>> Maybe it can be some "exit" tag that would be propagated to all blocks
>> in a flowgraph.
> In fact, GR does have something like that: It's a built-in message
> handler for a message port called "system"; see block.cc:60:
>
>  60     message_port_register_in(pmt::mp("system"));
>  61     set_msg_handler(pmt::mp("system"), 
> boost::bind(&block::system_handler, this, _1));
>
> You can send a "done" message there, and the block will set it's
> internal state to being done, ie work won't be called any more, the
> stream and message neighbours of that block will be informed to be done,
> too.
>
> By the way, the information you're looking for mainly resides in
> block.cc, block_executor.cc's "run_one_iteration" method, and
> tpb_thread_body.cc
>
> It's exactly the mechanism that happens when a block notifies its
> message neighbours to be done; for example, let ==> be a stream
> connection and --> a message connection
>
> msg_burster ---> some_kind_of_msg_to_stream ==> multiply_const ==> head
> ==> file_sink
>
> at some point, head's work method will tell the scheduler it's done. The
> scheduler will then inform head's stream neighbours (because head
> doesn't have any message neighbours) that they should be done, too.
>
> So file sink closes its file, mutliply_const is told to stop, and
> multiply_const then notifies its stream neighbours itself, and thus,
> some_kind_of_msg_to_stream is told to stop doing its thing, too.
>
> However, if these neigbours (which, remember, are all independently
> running threads!) are currently in their work() methods, then the
> scheduler won't (can't) interrupt that work call. That's all fine for
> things like multiply_const, where the work() will be done as soon as it
> has gone through the chunk of samples it's currently processing.
>
> For stream sources such as some_kind_of_msg_to_stream, the problem is a
> little more complex:
>
> Stream sources are usually designed to be blocking in the work() method;
> if that blocking doesn't have some timeout, then there's no way for that
> block's work() to ever stop blocking, and hence, the flow graph won't
> shut down, because the "system" message handler never gets called. In
> the some_kind_of_msg_to_stream source, the programmer must take care not
> to block in work() if there's nothing to produce, but just return 0 -
> meaning the source didn't produce anything. In the olden,
> pre-message-passing days, that would've been a great mistake, because a
> source producing nothing although there was the whole output buffer in
> space was declared finished, but nowadays, the scheduler can "revive" a
> source block not only when the free space in the output changes, but
> also if there's new messages to be handled. HOWEVER: this might still
> have bugs, and it might be that this is what you're encountering.
> Debugging your flowgraphs on a C++ and threat level when they ought to
> be exiting would be pretty interesting!
>
> Best regards,
>
> Marcus
>
> On 23.07.2016 08:43, Piotr Krysik wrote:
>> Hi Simone and all,
>>
>> Can you provide your GRC flow-graph? I think that source of the problem
>> might be somewhere in this part
>> "PMT MESSAGE TO FILE SOURCE" as there is message to samples stream
>> conversion involved here. But it's not clear for me what it actually is
>> as you described it.
>>
>> I have problems with automatic closing of a flow-graph that uses a block
>> that converts messages to samples. In my case it is PDU to Tagged Stream
>> block that caused problems with automatic exiting of the flow-graph.
>>
>> The constant problems with exiting of flow-graphs lead me to think if
>> these problems can be solved once for all with some change in gnuradio's
>> internals.
>>
>> Maybe it can be some "exit" tag that would be propagated to all blocks
>> in a flowgraph. This tag would be processed by all blocks and would
>> cause them to be marked as ready for the program exit. Blocks that have
>> stream inputs and message outputs would convert the tag to an "exit"
>> message, which would be propagated through the outputs.
>> Blocks with message inputs ans stream outputs would convert "exit"
>> message to an "exit" tag. When all blocks would be marked as ready for
>> closing the program would end.
>>
>> In this concept there is problem how to propagate the information to
>> blocks upstream, that might not have information about ending of a
>> flow-graph. So the method I described might be used as an addition to
>> current method of ending flowgraphs.
>>
>> What do you think?
>>
>> Best Regards,
>> Piotr Krysik
>>
>> W dniu 22.07.2016 o 18:40, Martin Braun pisze:
>>> Simone,
>>>
>>> a file source *will* terminate the flow graph once its read the file
>>> (unless you specify 'repeat').
>>>
>>> M
>>>
>>> On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote:
>>>> Goodmorning,
>>>> I would like to Know some methods to Close flowgraph automatically when
>>>> it has finished. Some example, stop when USRP has no more samples to
>>>> transmits, or a file source has read until EOF.
>>>> The Run of completion option works when (for instance) you have a file
>>>> source connected to other non-PMT Message block and a sink (USRP or null
>>>> sink...). However, when the file source output is converted to pmt
>>>> Message, then the flowgraph does not stop anymore when rhe file source
>>>> has finished. Probably because the PMT Message block continue to waits
>>>> for messages. In this case, How I can stop automatically the flowgraph?
>>>> I would like to Close the flowgraph when EOF or USRP has no more sample
>>>> to transmit, for example, in a situation like the following:
>>>>
>>>> FILE SOURCE -> STREAM TO PMT MESSAGE -> PROCESSING BLOCKS -> PMT MESSAGE
>>>> TO FILE SOURCE -> USRP SINK
>>>>
>>>> Thank for yours support and for the great utility of the list 😊
>>>> simone
>>>>
>

test_run_to_completion.tar.bz2
Description: application/bzip

test_run_to_completion.png
Description: PNG image