[Discuss-gnuradio] [Announcement] Ctrlport is broken -> potential candidate for removal in 3.8 -> RPC discussion

[Marcus Müller]

Dear GNU Radio community,

we've got an outstanding breakage in our controlport infrastructure.
Since fixing it seems to involve architectural changes to what
controlport does, and since making these changes would quite possibly
break the semantics of using controlport anyway, we're considering
removing Controlport from the GNU Radio 3.8 release (this does NOT
apply to 3.7).

The negative effect of that would obviously be that we'd lose
controlport (which I'm not going to introduce here; if you don't know
what it is, you haven't been using it). We would *not* lose the
performance counters, just the default way of querying them.

The most important upside would be the ability to remove the Apache
thrift dependency. Thrift has been the single worst thing we've relied
on for as long as I can remember in terms of availability and
consistency across platforms. In fact, different distros build
completely different configurations of thrift, and noone seems to be
able to build a "fully featured" thrift.

Another aspect to this is that albeit controlport is pretty cool in
theory – an adaptable RPC server within GNU Radio, with pluggable RPC
backends – its adoption has been slow to say the least, and it doesn't
really tie neatly into any GNU Radio applications I'd be aware of.

So, lest someone fixes the bug (I'll be describing it below), I'd
recommend we remove Controlport alltogether, and remove the thrift
dependency. I still stand by the very idea of controlport – having RPC
access to what a flow graph does – but in the end, there's a discussion
that we need to have: 

How do we want to do RPC in a way that enables us to make GNU Radio far
more machine-agnostic than it is? How does one not only allow for
gathering of statistics and calling of functions, but build an RPC
framework that makes heterogeneous and distributed GNU Radio really
feasible?

We've been addressing the question of what the scheduler needs to
become at the heterogeneous compute working group at GRCon'18. To
conclude, we need to get away from the "one buffer type fits all" and
"all blocks are born equal and are just individual OS threads" towards
domain-specific subschedulers and buffer managers. This is where this
needs to tie in.

Hence: Is anyone seriously using ControlPort and needs it for 3.8?
Please raise a metaphorical hand on the mailing list or write a private
one in response to this email.

Best regards,
Marcus

----------------------------------

Bug: clang correctly has been complaining for quite a while now that
the RPCAggregator stores a reference to a temporary object. It seems
that in the past this just worked by chance – probably, libc never
really got around to reassign the memory of these temporary objects and
all lived happily everafter. However, now on multiple platforms, we
just see aborts in various tests due to access to freed memory.
Probably memory protection just got smart enough to kick some sense
into this code.
All is fine as long as one doesn't actually use the code in question.