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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
