Using GNU libextractor from a multi-threaded parent process requires some care. The problem is that on most platforms GNU libextractor starts sub-processes for the actual extraction work. This is useful to isolate the parent process from potential bugs; however, it can cause problems if the parent process is multi-threaded. The issue is that at the time of the fork, another thread of the application may hold a lock (i.e. in gettext or libc). That lock would then never be released in the child process (as the other thread is not present in the child process). As a result, the child process would then deadlock on trying to acquire the lock and never terminate. This has actually been observed with a lock in GNU gettext that is triggered by the plugin startup code when it interacts with libltdl.
The problem can be solved by loading the plugins using the
EXTRACTOR_OPTION_IN_PROCESS option, which will run GNU libextractor
in-process and thus avoid the locking issue. In this case, all of the
functions for loading and unloading plugins, including
EXTRACTOR_plugin_remove_all, are thread-safe and reentrant.
However, using the same plugin list from multiple threads at the same
time is not safe.
All plugin code is expected required to be reentrant and state-less, but due to the extensive use of 3rd party libraries this cannot be guaranteed.
Loads a particular plugin. The plugin is added to the existing list, which can be
NULL. The second argument specifies the name of the plugin (i.e. “ogg”). The third argument can be
NULLand specifies plugin-specific options. Finally, the last argument specifies if the plugin should be executed out-of-process (
EXTRACTOR_OPTION_DEFAULT_POLICY) or not.