Polling in gNB ru_thread(): memory leak workaround
Using some drivers (at least 7.2 FHI), the ru_thread() uses polling to check for new samples to process (this is implemented in the radio driver, not in ru_thread(), but comes down to ru_thread() polling).
This can lead to memory leaks, as in this case, we send many messages in rx_func() that are not all properly received in ru_thread(). To avoid this, if-defs have been added in !2861 (merged), but a proper solution would be to avoid the memory leaks without conditionally compiling code.
What is expected to happen
No memory leaks without conditionally compiling code. A first start could be to try to avoid polling in the ru_thread, and use the normal L1 message passing mechanisms (without commenting code)
What happens instead
Memory leaks are avoided through ifdefs.
An unwanted side effect is that when compiling 7.2 support, it will not be possible to run the gNB with other radios, such as USRP or RFsim, because the commented code is necessary to trigger L1 processing in these radios, which do not use polling but block on the radio devices.
How to reproduce
To reproduce the memory leak, run OAI with 7.2 FH and with the commit from !2861 (merged) reverted. The memory leak should be visible in top.
watch -d 'ps faux | grep [n]r-soft'