Today I tried to run some experiments with Bob using python's threading module.
I created 8 parallel threads using Bob code, but I got only a single thread running at a time.
After discussion with André, he said that it's a python-related issue. It seems that python can run jobs only in a single thread.
BUT:
When we have some code implemented in C++, there is actually the *possibility* to run parallel threads. The way to achieve this is to unlock python's "Global Interpreter Lock" (GIL) before starting C++ code.
This can be done in the binding functions, by simply creating an object of the bob::python::no_gil class, e.g.
#include <bob/python/gil.h>
static void my_bound_function(...){
// set up python
...
// release the GIL
bob::python::no_gil no_gil_object;
// call C++ function
my_parallelizable_function(...);
}
The only thing to note is that the called function must be **thread safe**, which means that no memory is used internally to cache data.
Now, for most functions and classes of Bob, which perform long calculations, this GIL is not unlocked before execution. Effectively, this means that only one thread of Bob code can run in parallel (of course, you can have multiple processes, but no parallel threads).
As far as possible, it would be nice to change the bindings of those functions to include unlocking the GIL.
Since the thread safety of functions cannot be guaranteed, I would propose to have *two* versions of the function bound, one with and one without unlocking the GIL. The new functions might have a different name (e.g., adding a _nogil at the end) to be able to distinguish between them.
In any case, the user of these functions have to take care of the thread safety. E.g., when objects caches data, you can get them thread safe by copying the object in each of the parallel threads.
If I want to apply these changes in Bob, is there anything else that I have to take care of, and that I might have forgotten?
Cheers
Manuel