This is a very limited proof of concept to explore the limitations in newsched/pmtf of being to have a block do "double duty"
the work function is generally defined for streaming operation
every block gets a "pdus_in" and "pdus_out" message ports
when the block is switched into work_mode == PDU, streaming ports are allowed to be unconnected
the handle_msg_pdus_in handler in block.cc - does a lot of wrangling to get the pdu vector into a buffer. This is the part that should be mostly replaced by some magic in pmtf
Current limitations:
no pdu datatype in pmtf, so just using a map for now, which leads to some uglier api
pmt vectors must be typed, whereas it would be nice to get a uint8_t* to the data with a size in bytes - essentially a pointer to the blob with how big that blob is, and then let the block work function figure out how to handle the data.
pushing data through the work function in to out requires that an output pdu is created, and the size known, which implies some sort of forecasting (which we removed). Can use relative_rate, but is that always accurate?
If sync_block, should not be a problem
do pdus being pushed through a work function have the possibility to use the same buffer within the limitation that the block can do inplace memory? then just modify the pdu as it gets passed along. would also have a 1 output limitation
Here is an example of the same block doing "double duty":
This is a very limited proof of concept to explore the limitations in newsched/pmtf of being to have a block do "double duty"
block.cc- does a lot of wrangling to get the pdu vector into a buffer. This is the part that should be mostly replaced by some magic inpmtfCurrent limitations:
uint8_t*to the data with a size in bytes - essentially a pointer to the blob with how big that blob is, and then let the block work function figure out how to handle the data.Here is an example of the same block doing "double duty":