[Top][All Lists]

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

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

From: Michael Dickens
Subject: Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"
Date: Thu, 8 Jun 2006 09:01:59 -0400

* p56, 4.6.4: "These items are typically floats, doubles or complex

--> 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

reply via email to

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