|
Hi Piotr,
I let gdb loose on your minimal example [1], and found this:
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 }
Sylvain, who replaced the delete_head_nowait with the
delete_head_blocking call correctly pointed out the reason to do
so in his commit message(838793ce):
blocks: Fix pdu_to_tagged_stream CPU
spinning using blocking with timeout
This is not ideal, but until the scheduler supports something
better, this
will have to do.
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. For
tagged stream blocks, my knowledge of the scheduler control flow
isn't as reliable as for regular blocks :/
Best regards,
Marcus
[1] http://marcus.hostalia.de/screencast/run_to_completion.html
On 23.07.2016 19:41, Piotr Krysik
wrote:
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|