Hi Piotr,
Post by Piotr KrysikMaybe 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
Post by Piotr KrysikHi 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
Post by Martin BraunSimone,
a file source *will* terminate the flow graph once its read the file
(unless you specify 'repeat').
M
Post by Simone Ciccia S210664Goodmorning,
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio