Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()

[Nowlan, Sean]

Any block can return "DONE" to indicate the scheduler that it finished its 
processing. Then the scheduler tells downstream blocks that they are DONE too. 
However, it's possible that you want downstream blocks to finish operating on 
samples that are "in flight" after the upstream block is marked DONE, rather 
than terminating everything before those buffers have been flushed/processed. 
Wouldn't it make sense to have the scheduler let these buffers flush before 
notifying those blocks that they are DONE? (Or does the scheduler already do 
something like this, and I've just not noticed?)

________________________________________
From: address@hidden address@hidden on behalf of Tom Rondeau address@hidden
Sent: Thursday, September 12, 2013 9:45 AM
To: Mark Cottrell
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling 
wait()

On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell
<address@hidden> wrote:
> Hi Tom,
>
> I spent a while playing around with this, including adding a bunch of debug
> output to tpb_thread_body::tpb_thread_body, and found that when a block is
> done, the DONE state should propagate through the flow graph as
> tpb_detail::notify_neighbours is called (as I'm sure you're aware).  The
> problem is, tpb_detail::notify_neighbours only notifies blocks that that
> have input or output buffers (which as far as I can tell, blocks with only
> message inputs or outputs don't), so blocks like message_debug will block on
> tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can
> never be notified (as it has no input buffers, so notify downstream does
> nothing).
>
> Johnathan contacted me r.e. this and I sent him a patch which fixed the
> problem for me (attached to this message), but I don't think he has had time
> to look at it yet.  The gist of it is that it uses pmt::PMT_EOF to indicate
> that message blocks should transition to done and notify neighbours.
>
> Please feel free to correct me on any of what I said above, this was my
> first foray into the scheduler so I could have it completely wrong.
>
> Thanks,
> Mark

Yeah, ok, I see the problem. I think I remember now someone else
talking about this potential issue.

I'll discuss your patch with Johnathan sometime soon. I see where
you're going with it, but I'm hoping that there's a solution that's a
bit simpler (or just fewer changes).

Thanks,

--
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13


> On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau <address@hidden> wrote:
>>
>> On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
>> <address@hidden> wrote:
>> > Hello all,
>> >
>> > I have written a sync block that takes in samples and outputs messages
>> > (similar to tagged_stream_to_pdu), but when writing a test for the block
>> > I
>> > found that when I called top_block.run(), the test never finished, as it
>> > appears to be hanging on the call to top_block.wait().
>> >
>> > The flow graph for the test is as follows:
>> > non-repeating file source -> my block -> message_debug
>> >
>> > is hanging the expected behaviour?  I can work around it by counting the
>> > number of items written by the file source, but it would be nice to have
>> > it
>> > terminate of its own accord.
>> >
>> > Thanks,
>> > Mark
>>
>>
>> Mark,
>>
>> No, that's not expected behavior. When the file sink finishes, it
>> should set the DONE stage in the scheduler that should indicated to
>> every down stream block that they are also done.
>>
>> Make sure that there isn't something happening where your block isn't
>> getting stuck in 'work' at this point.
>>
>> --
>> Tom
>> Visit us at GRCon13 Oct. 1 - 4
>> http://www.trondeau.com/grcon13

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio