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 buffe//r/ 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
> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
