Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"

[Michael Dickens]

> > * p56, 4.6.4: "These items are typically floats, doubles or complex
> > values."
> >
> > --> I would rewrite this to state that "These items can be any
> > standard C/C++ element, including ints, floats, doubles, complex
> > values, and even structs."  Yes, I've done testing on structs and
> > it's possible to send those around.  It's easiest when their size is
> > "small", but possible no matter their size.
>
> In reality, it will work with any C++ element for which memcpy is a
> valid copy constructor.  This includes many structures and classes,
> but not all.

You get my point.  "floats, doubles, and complex values" is too  
limiting.  Not that one needs to be all-inclusive, but int's are a  
big part of what's passed around and leaving them out seems like a  
crime ;-)  Structs or classes can be left out, but I think any C- 
struct can be passed around (since it's just a bit of structured  
memory with no methods attached to it) and thus something should be  
included as a voice for the power of the current GR capabilities.

> > * p67: Could there be some text about what "C1" and "C2" are, and how
> > they are connected to the new m-scheduler?  Are they invoked by the
> > encompassing m-block, as part of it's data processing?
>
> They are mblocks "contained" in the one illustrated.
>
> Containment has *zero* to do with scheduling; it's for managing
> complexity / reuse.  There is only a single mblock scheduler, and it
> schedules *all* messages across *all* mblocks, nested or not.

Ah, that's what I thought.  I don't remember reading this anywhere.   
I will try to reread (for the ?'th time) and find an appropriate  
place for it, sometime in the next few days. - MLD