Re: [Discuss-gnuradio] Can a tagged stream block be a source block?

[Martin Braun]

On 12/04/2014 10:23 PM, Nowlan, Sean wrote:
>> This was actually simpler than expected: 
>> https://github.com/mbr0wn/gnuradio/tree/tsb/allow_source
>> 
>> I also put an example in there (see the 2nd commit).
>> 
> Just to understand the implications of this change to pdu_to_tagged
> stream, max input PDU size is now effectively constrained by the max
> buffer size that can be handled by the scheduler and passed to
> work(). Correct? That may not be a limitation for many people, and I
> suppose it would have surfaced before if someone tried to send a
> larger PDU into a pdu_to_tagged_stream block connected to a
> downstream tsb-derived block.

Exactly. It kind of adds a new constraint, but not really, because
downstream blocks already bring this constraint with them.

> I guess the upside is that now you only need one call to work() per
> PDU and you don't need an internal buffer and a stateful work() to
> push a PDU through.

Not quite, unfortunately: With or without usage of TSBs, we need to spin
inside work. I gave it a rough benchmark (using htop), and both versions
of pdu_to_tagged_stream use up a lot of cycles. This would probably be
better if we blocked on popping the message Q, but that's something we
don't want in work functions.

The statefulness is still gone, though. If we're spinning on work
because the Q was empty, it returns pretty much immediately. Otherwise,
the work() function is much tidier and uses less copying to intermediate
buffers.

We could probably sack all the class attributes if we popped the message
Q inside work() instead of (ab-)using calculate_output_stream_length(),
but the point of that method is to provide the parent block with the
correct output length, for which we need to read the PDU.

More importantly, we remove TSB tag handling from that block. If we go
to tagging the last item, we want no blocks to do the TSB tag handling
themselves.

M