Accumulating into output_items[0] across multiple general_work()
Wael Farah <[email protected]> Thu, 4 Jun 2026 18:27:14 -0700
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_896265A5-646E-40C5-AE2E-2A62C290B700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I have a block whose output items are running averages over a long = integration (for the sake of simplicity say a power spectrum accumulated = over millions of FFT frames, way too many to hold as one input buffer). The implementation that fell out naturally is: in general_work(), add = the next batch of partial contributions directly into = output_items[0][n_emitted], return 0 while the integration is still = incomplete, and only return n_emitted > 0 when one or more integrations = are done. It's pretty tempting to do as this would practically avoid an = extra memory allocation for an internal buffer and a memcpy back to = output_items when accumulation is ready. However, this relies on the assumption that returning 0 leaves the write = pointer unadvanced, so the next general_work() call sees the same memory = at output_items[0][n_emitted] and I can keep adding into it.=20 As far as I can tell, this works on current GR (no-op when = produce_each(0) = <https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/block= _detail.cc#L123-L132> -> write pointer not updated), but it=E2=80=99s = more like an implementation detail rather than it being documented as = part of the scheduler API. Two questions: 1) Is the "accumulate into output_items[0] across calls" pattern = supported, or am I in undocumented/unidentified scheduler/buffer = behavior territory? 2) If it's not supported, is there any reason beyond "no API = guarantee=E2=80=9D; e.g. would it break under certain custom buffers or = futuristically GR4? If the answer is just "use an internal buffer," happy to refactor. Thanks! Wael= --Apple-Mail=_896265A5-646E-40C5-AE2E-2A62C290B700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Hi all,<div><br></div><div>I have a = block whose output items are running averages over a long integration = (for the sake of simplicity say a power spectrum accumulated over = millions of FFT frames, way too many to hold as one input = buffer).</div><div><br></div><div>The implementation that fell out = naturally is: in general_work(), add the next batch of partial = contributions directly into output_items[0][n_emitted], return 0 while = the integration is still incomplete, and only return n_emitted > 0 = when one or more integrations are done. It's pretty tempting to do as = this would practically avoid an extra memory allocation for an internal = buffer and a memcpy back to output_items when accumulation is = ready.</div><div><br></div><div>However, this relies on the assumption = that returning 0 leaves the write pointer unadvanced, so the next = general_work() call sees the same memory at output_items[0][n_emitted] = and I can keep adding into it. </div><div><br></div><div>As far as = I can tell, this works on current GR (<a = href=3D"https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/li= b/block_detail.cc#L123-L132">no-op when produce_each(0)</a> -> = write pointer not updated), but it=E2=80=99s more like an implementation = detail rather than it being documented as part of the scheduler = API.</div><div><br></div><div>Two questions:</div><div>1) Is the = "accumulate into output_items[0] across calls" pattern supported, or am = I in undocumented/unidentified scheduler/buffer behavior = territory?</div><div>2) If it's not supported, is there any reason = beyond "no API guarantee=E2=80=9D; e.g. would it break under certain = custom buffers or futuristically GR4?</div><div><br></div><div>If the = answer is just "use an internal buffer," happy to = refactor.</div><div><br></div><div>Thanks!</div><div>Wael</div></body></ht= ml>= --Apple-Mail=_896265A5-646E-40C5-AE2E-2A62C290B700--