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 On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau <t...@trondeau.com> wrote: > On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell > <mark.cottr...@taitradio.com> 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 > -- ------------------------------ This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ------------------------------
async_message_stopping3.patch
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
