Questions on multiple outputs and produce()

Hi list,

Since the API for gr_blocks with multiple outputs was changed a bit with
version 3.3.0, I have a couple of questions.

  1. 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?

  2. 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?

  3. 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)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

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.

  1. 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.

  1. 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.

  1. 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.

Eric

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)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs