|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Flowgraph with loops |
Date: | Wed, 17 May 2017 10:54:54 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
Adding to that, because it comes up every couple of years: Marcus is right, GNU Radio's scheduler will just bark at you and
refuse to work if the flow graph has cycles. I don't fully agree with the statement that it's due to buffer
management: I've patched away that refusal to work on a longish train ride some time ago, and in theory, with the Thread-Per-Block (TPB) scheduler, it *would* work. However, of course, you're running into causality problems if none of the blocks in the feedback path creates items out of thin air, and the block where feedback and forward items "merge" needs an item on every input. So, realizing that this refusal to work is a result of GNU Radio originally being written only with the single-threaded scheduler (STS) in mind, and is a remnant of us never really having codified or formalized the boundaries between blocks, block execution, scheduling, and flowgraph initialization, I kinda stopped there, and never wrote the unit and integration tests, wrote docs or figured out a way to test whether such a flow graph could work before actually letting it start to run. It just seemed wiser to first tackle the fact that we don't really have a formal description of how the scheduler should behave before changing what it refuses to do (and, possibly, for good reasons that I didn't have in mind). Now, fast forward a while, what a surprise!, that plan of formalizing what GR is supposed to do never saw execution; it's not really a weekend project. But: this whole thing has gotten traction over the last couple of weeks, so maybe we'll come up with something. Cheers, On 16.05.2017 22:39, Marcus D. Leech
wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |