[Discuss-gnuradio] Flow Graph Flow Control (was: Re: Code Reuse Question)

[Marcus Müller]

Hi Johnathan,

blocks can't side effect each other except through really strictly controlled, well-defined ways

... and that was still very clear and dominant to the user under GR 3.4, I agree – then we "softened" that concept by adding stream tags, message passing, and if you look at things like the ofdm_rx.grc, you'll notice that there's extensive use of shared state through using the same equalizer object for payload and header and so on.

So, there's two conflicting opinions I have about that

* it's obviously a good thing we have all those mechanisms. An SDR framework without any chance to communicate in-band side information (tags) or asynchronous commands / info (msgs) is bound to be hell to use. Same goes for shared equalizer, coder, constellation objects. It's absolutely necessary, and it's of great use without being too confusing. Not that documentation couldn't be better… but that's kinda my fault by now, I think.
* The whole python variables/callback/GRC-generated code thing is great for ad-hoc GUI things, but it has led to numerous cases of people being in confusion on how to make blocks "talk" to each other. It's unclean, and maybe we should look into how we can reduce usage of that in favour of replacing it either by explicit application of e.g. message passing, or implicit RPC (which we'd still have to come up with a consistent method for).

This includes not being able to modify their upstream block's output buffer, as potentially many other blocks are also reading that upstream output buffer.  (There are no "input buffers" in GNU Radio, only input ports that maintain a read point to upstream-owned memory.)

Totally agreeing with you on that "don't mess with someone else's output buffer" contract – I should have been more careful with my words here.

OK. Time for lucid dreaming:

Src +--> Head ---> Sink0
    \------------> Sink1

In essence, the idea would be to have the src output buffer acting as head's output buffer, but with another (non-writing, just write pointer handling) buffer writer attached to it (and Sink0's read pointers using that one), making sure that downstream read pointers can't pass limits that the head block defines. That would naturally be something like min(src_write_pointer, head_pseudo_write_pointer). Alongside with that would actually go something like the same flow/execution control influence (because we can basically emulate something like that half-way by having a "limiting" reader attached to the upstream block, so that that block's write pointer can't advance even if the sink1's read pointer indicates sink1 has consumed what src produced) a "proper" block has.

From a behavioral point of view, this would be like having the read pointer of sink0 directly attached to src's output buffer. Now, the trick is that for "normal" connections, the limit of how far that read pointer can advance is given by the position of src's write pointer. Now, if head had its own pseudo-write pointer that might sit somewhere behind (up to) src's write pointer, consider how nicely we could implement all non-modifying operations that up to now would need a copy – peak taggers, the infamously misunderstood throttle block (which we suddenly could really rewrite to let samples through at a fixed rate – simply advancing the the pseudo-write pointer every hundred µs by one, for example), event counters, channel estimators.

Hm. Maybe after Grcon; thinking about this, this doesn't need any special buffer handling.

Cheers,
Marcus

On 12.05.2016 22:32, Johnathan Corgan wrote:

On Thu, May 12, 2016 at 9:18 AM, Marcus Müller <address@hidden> wrote:

 

Yeah, like the head block, it's a copying operation. But that's "relatively cheap".
I'm not quite sure about the state of this, but at GRCON '14 work was started on letting blocks define where their buffers are – maybe, one day, as a side effect, we can actually use the same buffers for in- and output and get rid of the copying.

It probably should be the subject of another thread, but one of the deep underlying philosophies of GNU Radio design is that blocks can't side effect each other except through really strictly controlled, well-defined ways.  This includes not being able to modify their upstream block's output buffer, as potentially many other blocks are also reading that upstream output buffer.  (There are no "input buffers" in GNU Radio, only input ports that maintain a read point to upstream-owned memory.)

We do have a branch that was developed by Doug Geiger that allows blocks to provide their own memory for their output buffer, or to provide their own memory to an upstream block for it's output buffer.  This was spec'd and written to support custom hardware that could only work on it's own physical pages or had DMA restrictions or some other constraint.  However, it still maintains the idea that you cannot modify the contents of an upstream block's output buffer.

-Johnathan