[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] About closing flowgraph automatically
From: |
Simone Ciccia S210664 |
Subject: |
Re: [Discuss-gnuradio] About closing flowgraph automatically |
Date: |
Sun, 24 Jul 2016 09:16:10 +0200 |
User-agent: |
Roundcube Webmail/1.2-rc |
Goodmorning list,
thanks to everybody for your replies.
I attached a minimal example illustrating the problem.
Specifically, the block that causes the non stop behavior is the
[PDU to tagged stream], the same encountered by Piotr and discussed in
the other replies.
In my case we can restrict this problem in how to signal to PDU to
tagged stream to finish.
If I understand, correct me Marcus, for PDU to tagged stream I need to
use some timeout to monitoring input message.
When timeout expires and no input message is present, then the block
returns zero.
This is exactly what PDU to tagget stream does:
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 }
My doubt is, how can we signal and stop the execution of this block?
If there some idea I have time to trying to thinking to
modify/ameliorate this block and discuss with you.
Thank you,
simone
Il 2016-07-24 08:04 Sylvain Munaut ha scritto:
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
MInimalExample.grc
Description: application/xml
file_to_tx
Description: Text document
- [Discuss-gnuradio] About closing flowgraph automatically, Simone Ciccia S210664, 2016/07/21
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Martin Braun, 2016/07/22
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Piotr Krysik, 2016/07/23
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Marcus Müller, 2016/07/23
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Piotr Krysik, 2016/07/23
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Marcus Müller, 2016/07/23
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Sylvain Munaut, 2016/07/24
- Re: [Discuss-gnuradio] About closing flowgraph automatically,
Simone Ciccia S210664 <=
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Marcus Müller, 2016/07/24
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Marcus Müller, 2016/07/24
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Bastian Bloessl, 2016/07/24
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Marcus Müller, 2016/07/24
- Re: [Discuss-gnuradio] About closing flowgraph automatically, Simone Ciccia S210664, 2016/07/27