Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix module loading in multi-threading environments #13823
When ansible loads a module from disk for a plugin, it first checks
When a module is loaded, the reference is immediately added to
This change wraps the method which checks for existence in
When ansible loads a module from disk for a plugin, it first checks to see if the module has already been loaded (i.e., exists in sys.modules), and if it does, it returns that reference rather than loading the module again (which, as described in issue #13110, must not happen because repeating the module load may re-initialize module global variables). When a module is loaded, the reference is immediately added to sys.modules, even before the module initialization is complete. Therefore, if two threads race the module loading code, the first will begin loading the module from disk, and the second will see the module in sys.modules. It might begin using that module before it is even fully loaded, resulting in AttributeErrors on objects which should be defined in the module. This change wraps the method which checks for existence in sys.modules and loads modules from disk in a global mutex so that more than one module is never loaded from disk at a time. Fixes #13822
Ansible's API has never been advertised as being thread-safe, as we use the multiprocessing library (which does everything in forks). This patch may fix the module loading issue, however I'm sure there are many other places in the code which may harbor similar race conditions. As such, I'm not particularly opposed to this patch, however I am against trying to make the entire API thread safe.