Since the API for gr_blocks with multiple outputs was changed a bit with
version 3.3.0, I have a couple of questions.
The return value for general_work() is no longer relevant for the
number of produced output items. Does this eliminate the need to produce
all output values at the same rate?
If I still want to (or have to) produce all output items at the same
rate, wouldn’t it be great to have a produce_all() member function,
analogous to consume_all()? Is it just waiting to be patched in, or if
not, what’s the rationale for not including it?
If it’s possible to produce output at different rates, how does
forecast() work? IIUC, forecast() returns the number of input items on
every input stream to produce noutput_items output items. But for which
output stream is this valid?
On a similar note, what meaning does noutput_items in general_work()
have?
Hmm…
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
On Thu, Oct 21, 2010 at 05:06:26PM +0200, Martin B. wrote:
Hi list,
Hi Martin!
Since the API for gr_blocks with multiple outputs was changed a bit with
version 3.3.0, I have a couple of questions.
The return value for general_work() is no longer relevant for the
number of produced output items.
It’s still relevant, unless it has the value WORK_CALLED_PRODUCE
(I just noticed that the docs for general_work were not updated to
reflect this change. Sorry about that.)
Does this eliminate the need to produce all output values at the same rate?
Yes. That was the reason for the change.
If I still want to (or have to) produce all output items at the same
rate, wouldn’t it be great to have a produce_all() member function,
analogous to consume_all()? Is it just waiting to be patched in, or if
not, what’s the rationale for not including it?
To preserve the original behavior, non-negative values of the return
value are treated as they were before, in effect calling produce_all.
If it’s possible to produce output at different rates, how does
forecast() work? IIUC, forecast() returns the number of input items on
every input stream to produce noutput_items output items. But for which
output stream is this valid?
On a similar note, what meaning does noutput_items in general_work() have?
None of the behavior (or implementation) of those routines has
changed. Thus, for any given value of noutput_items, there is
guaranteed to be enough output buffer space on each output stream to
hold noutput_items.
Probably the easiest way to think about this, is that it allows you to
return fewer results on one or more output streams than the number
returned on the stream returning the maximum number of output streams.
On Thu, Oct 21, 2010 at 09:11:50AM -0700, Eric B. wrote:
None of the behavior (or implementation) of those routines has
changed. Thus, for any given value of noutput_items, there is
guaranteed to be enough output buffer space on each output stream to
hold noutput_items.
Probably the easiest way to think about this, is that it allows you to
return fewer results on one or more output streams than the number
returned on the stream returning the maximum number of output streams.
As usual, thanks for the helpful answer!
That clears it all up, I thought I’d found an inconsistency in the
API–a fix to the docs would still be great, though.
Cheers,
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)