Dear GR community, first: thanks for all your good work!
I am currently stuck trying to unit-test a pure message passing block and hope that someone might have an idea or encountered a similar problem. If this has been asked before I am happy for pointers but did not find anything myself. Block purpose: receive a message via UDP, deserialize, filter and pass interesting content on as pmt message. As I have no stream items to work with, i use a general block, without a work function. Similar to the message strobe (in gr-blocks) it starts a thread in the start() method. In there it queries a UDP port and does the rest (with a settable condition variable to stop the thread). I already added a c++ unit test to test all involved conversions, but I would like to add a python unittest with connected blocks to test if the block behaves as expected. This pattern does not seem to be uncommon, but I did not find a single instance with existing unit tests unfortunately.. Problem: when executing the python unit test, self.tb.run() blocks forever as the thread does not terminate. This only happens if the block is connected to another one in the flow graph. So far I tested: - to add a timeout [1] via the timeout-decorator module, which does terminate the unit test "in time", but makes it fail/interupt - adding a message input port to the block under test, which sets the terminate condition variable. Then I could use the .to_basic_block()._post(..) method in the unit-test to trigger that. Problem: have to do that before run() (otherwise run blocks) and then it does not seem to have the intended effect. Might be, because the blocks need to be started by the run() to be processing it correctly via the callbacks?!? - adding a class function to do the interrupt seem to have the same limitation as above, plus the challenge to make it accessible to python.. These were my ideas worth mentioning. If anyone has others or know the solution, I would be very greatful! System: GR maint-3.8 (6aad98) , ubuntu 20.04 I created a striped down minimal example of my problem here:https://github.com/lenhart/gr-test-msg-passing-block-issue Thanks! Bonus questions (unrelated/informational) : - FAQ item [2] about linking required packages seem to be outdated. should |set(GR_REQUIRED_COMPONENTS RUNTIME <YOUR COMPONENTS>)| be replaced by target_link_libraries(gnuradio-project XXX) ? (+cmake of lib folder instead of top level). And if so, should I just change it in the documentation? - It took me a while to hunt down another "bug": instantiating the test block in the python test caused a std::system_error for invalid arguments. The problem however was, that I had exchanged the gr_thread to the std::thread as I had in mind to use modern std components as much as possible and to avoid the boost::bind. In hindsight it makes sense that gr has a modified thread version, but I thought I mention it as it might occur more often and is potentially hard to track. Running the block outside the testbench worked without problem (or maybe the error was just not obvious there), but the join() in the destructor caused the test to fail.. could there be a way to make it fail more explicitly so that the error message made any sense? (i spent quite some time to try fixing the problem elsewhere..) [1] https://stackoverflow.com/questions/34743448/how-to-specify-test-timeout-for-python-unittest#34743601 [2] https://wiki.gnuradio.org/index.php/FAQ#In_my_OOT_Module.2C_I.27m_trying_to_use_a_GNU_Radio_block_or_class_but_get_an_ImportError_.22undefined_symbol.22._What_do_I_do.3F
OpenPGP_signature
Description: OpenPGP digital signature
