Eric Blossom wrote:
>
> Let's say that block D never produces an output, but is consuming all
> of it's input. Can you see how this leads to a hang?
>
I can see that will cause the flow graph to hang. And I followed your
explanation.
I have added a "timeout" feature to block D, so that after
Eric Blossom wrote:
>
> What you're trying to do requires unbounded memory in the worst case.
> Perhaps you should consider another way to organize your computation?
>
But this isn't happening in my scenario. If necessary, I can add an event
timeout or maximum size event value to prevent this
Eric Blossom wrote:
>
> The bug is that D should always produce an enable output, 1:1 with the
> input. If you're not sure of the state at start up time, output a
> reasonable default value.
>
I guess I would agree with your 1:1 statement if I was using a
gr_sync_block. And I may not have pr
Okay I am using the default scheduler. So now I have enabled the logging for
the appropriate thread-per-block scheduler files.
Here's the heart of my problem. My flow graph has five blocks, A, B, C, D,
E.
Output of A is input to B and C.
Output of C is input to D.
Output of B and D are input to E
I have a question about the scheduling of work.
In 'gr_single_threaded_scheduler.cc', I changed the pound-def ENABLE_LOGGING
from 0 to 1.
I did a 'make' and then a 'make install'.
However, when I execute my flow graph, the log file is not generated.
Is this not the file of interest to investigat
