Re: [Discuss-gnuradio] About closing flowgraph automatically

[Simone Ciccia S210664]

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