Re: [Discuss-gnuradio] complex examples

[Eric Blossom]

On Tue, Sep 20, 2005 at 09:29:34AM -0500, Jim Lindstrom wrote:
> On 9/19/05, Eric Blossom <address@hidden> wrote:
> 
> - augment the existing code to include a publish/subscribe abstraction, 
> perhaps based on the existing message queue implementation

This is easy from the python side, especially if you use weak
references (http://docs.python.org/lib/module-weakref.html) to keep
track of the folks to be notified.

> - refactor things (probably fairly invasively) to use a state-machine 
> abstraction for each block. there are some good open-source state machine 
> backends that we could use. 

Not sure that this would require much refactoring.  It would appear
that only the blocks that wanted to take advantage of a state-machine
abstraction would require change.  Am I missing something?

It could be that we have two non-exclusive abstractions for blocks.
One would be the existing data flow abstraction, the other could be
event / message based.  I can imagine blocks inheriting from both.

Also, it seems that depending on where in the protocol stack you're
operating, some operations are a better fit for packet/message based,
while other fit nicely in the data flow "stream of samples"
abstraction.  Having both would be nice, especially if we can find a
clean and elegant way to have them play together.

The Click Modular Router does a nice job on the packet based idea.
They support both "push" and "pull" based processing, with message
queues between paths with different sexes.  Perhaps there's some way to
connect this all together.

> The scheduler could be merged into the top-level 
> code, and message passing could be done by broadcast (publish/subscribe) or 
> directed messages.

Not sure what you mean by "merged into the top-level code".
I agree on the publish/subscribe idea.

> - have some concept of control ports and connect them together just like you 
> connnect the data lines in the assembly.

I've also thought about control ports, but thought that since
gr_msg_handler's are first class objects, anybody who cared on either
the C++ or Python side could send to any msg_handler they've got
a handle for.  Note that gr_msg_queue is derived from gr_msg_handler.

That said, I'm not opposed to control ports, feel free to propose
and/or implement something.

One thought was to give each block a default message queue and
dispatch method (top of state machine / state-chart engine) that would
be run at a convenient (thread-safe) time.  Any kind of state machine
could be hung off of this.


> Any thoughts?

Long ago, in a galaxy far far away, I built a state-chart
compiler and runtime system that was used as part of the real-time
control in a line of secure phones.  Besides the state-chart
abstraction, it also included hierarchical blocks with unidirectional
typed message ports.  This was based on the "Real Time Object-Oriented
Modeling" (ROOM) ideas described in a book of the same title by Selic,
Gullekson and Ward.   Sometimes it seemed like more structure that I
wanted.  Being able to send a message to anybody you can see is
sometimes very helpful.

Great to have your ideas on this stuff!

Eric