Hi, I've been writing some blocks which use the new 3.6.3 message-passing API, and I've run into some issues writing QA code for blocks which accept message input and produce stream output. It seems that there are some cases where blocks which use message-passing primitives are never automatically marked done by the scheduler, meaning that either blocks need to include some mechanism for manually setting their done flag based on some magic input (such as an empty message) or that the QA code needs to check the done flags of upstream blocks manually and end the flow-graph when there's no more data upstream (requires exposing the done() function to python if python QA code is used, and there doesn't seem to be a way to verify that downstream blocks are complete). Neither option seems particularly appealing.
Looking at the scheduler code, it seems that the message-passing primitives aren't handled by the scheduler at all, leading to at least five cases where message-passing blocks behave differently from stream-only blocks: 1) Stream output, message input: The block is not marked done when upstream blocks on the message input are marked done. 2) Stream input, message input: The block may be automatically marked done when the upstream block on the stream input is marked done, even though messages may still arrive on the message input. 3) Stream output, message output: Same issue as case 2, except for downstream blocks. 4) Stream input, message output: The block is not marked done when downstream blocks on the message output are marked done. 5) Message input/output only: The block is not marked done when upstream or downstream blocks are marked done. I've only seen what I believe to be the first case in practice, so it might be that the other cases are handled somewhere that I've missed. I've considered altering the scheduler to handle message-passing blocks myself but I'm not sure I fully understand why the message-passing code is implemented the way it is and I don't want to do anything to it until I'm confident I won't break something subtle, which leads me to the 'questions about' part of this email: Does gr_hier_block2 use the message queues (other than to connect them), and if so then where and for what purpose? If not, then why are message queues implemented in gr_basic_block and not gr_block alongside the stream buffers? And finally, is there any reason why the message queues aren't encapsulated in a separate class like the stream buffers are? Regards, Fiach Antaw _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
