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

[Johannes Demel]

Hi Marcus,

it seems like Thrift is a painful dependency. So, this is a pro ctrlport 
removal. Though, what else does ctrlport removal entail?
Is it really only used for monitoring and control?
Just for clarification, the zeromq blocks are not affected?
How will the performance monitor be preserved? I really like to look at 
the statistics to get a first idea where to look for problems and 
analyze my system with it.

Also, in case ctrlport is removed, we should have a GREP to discuss what 
we want and how we want ctrlport back in some other form.

Cheers
Johannes

Am 24.03.19 um 20:26 schrieb 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.
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>