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
–
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.
On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
[email protected] wrote:
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
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 R. [email protected] wrote:
The flow graph for the test is as follows:
Tom
Visit us at GRCon13 Oct. 1 - 4
GNU Radio Conference 2013 — Rondeau Research
–
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.
On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell
[email protected] wrote:
never be notified (as it has no input buffers, so notify downstream does
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
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: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of Tom R. [[email protected]]
Sent: Thursday, September 12, 2013 9:45 AM
To: Mark Cottrell
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] flowgraph with async messaging hangs on
calling wait()
On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell
[email protected] wrote:
never be notified (as it has no input buffers, so notify downstream does
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
appears to be hanging on the call to top_block.wait().
Mark
–
Tom
Visit us at GRCon13 Oct. 1 - 4
GNU Radio Conference 2013 — Rondeau Research
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio