discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Message queues - Message-passing blocks are never mar


From: Fiach.Antaw
Subject: [Discuss-gnuradio] Message queues - Message-passing blocks are never marked done?
Date: Mon, 14 Jan 2013 13:28:50 +1100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]