Issue #727: Comparison between Python processes and threads for RADI

This is related to Issue #727.
I read about the pros and cons of threads vs processes and I wanted to understand RADI’s architecture better to appreciate the benefits. I feel that the low memory footprint is a great characteristic of python threads. Does any of the listed cons limit the potential of RADI, where we would benefit greatly from using python processes?

Hi @trunc8 ,

we have already done that study :slight_smile: RADI includes (a) the software dependencies for all exercises (such as OpenCV, MoveIt, MAVROS, etc…) already preinstalled and (b) the exercise.py for each exercise. In RoboticsAcademy each exercise has a template, which is composed of two parts: exercise.html and exercise.py.

Exercise.py typically includes four modules: (b1) HAL, provides access to robot sensors and actuators, just connecting to Gazebo or to the real robot drivers; (b2) GUI for specific Graphical User Interface in the browser, it connects to exercise.html using a websocket; (b3) BRAIN, runs the user’s code on iterations at a controlled frequency; (b4) MANAGEMENT, receives the user’s code from the browser.

Right now (b1)(b2) and (b3) are implemented using Python threads. This way they all run on the same Python interpreter, and so we do not take benefit of the multiple cores of the user computer. Their implementation as Python processes is intended to take advantage of those multiple cores and so speeding up the exercise.py execution. In this case, attention must be put in the communication between (b3) and (b1), or between (b3) and (b2), through shared memory, to avoid any race condition.

1 Like