Calling C++ Module Function From python asyncTask

Scripting Issues
1

Hi all,
A direct question, calling a c++ module function from python within an asynctask, especially when the function deals with procedural geometry, doesn’t seem to do so asynchronously, for example:

taskMgr.setupTaskChain('chain_name', numThreads = 1, tickClock = None,threadPriority = None, frameBudget = None,frameSync = True, timeslicePriority = None)
taskMgr.add(self.pyAsyncTask,"pyAsyncTaskNom", taskChain = "chain_name")

...
def pyAsyncTask(self):
      cpp_module.generateSphere()
      return task.cont

Just seems to call generateSphere from the main thread, despite python calling it within an asyncTask. Is there a directive I’m supposed to add on the c++ side before building the module, or is it just that any asynchronous processes involving a c++ module must be written in c++ and not python?

Thank you in advance.

2

In principle it should call it from the alternative thread, are you sure it’s calling it from the main thread?

What you might notice is that it doesn’t release the GIL, which is something your C++ wrapper / function needs to explicitly do. If you use interrogate, putting the BLOCKING keyword in front of the function declaration should do this.

3

Thanks for the swift response! Adding BLOCKING before the function declaration like so:

BLOCKING void generateSphere()
{
...;
}

Did indeed release the GIL. I wonder though if calling an asyncTask from c++ would be faster than calling it in python, i.e. if a c++ module initiates an asyncTask, would that be genuine threading as opposed to the ping-ponging done by the GIL in a python asyncTask?

EDIT:
I got the answer here: Panda3d Threading and Python Global Interpreter Lock
It’d be better to use a c++ asyncTask as it avoids the python GIL and its limitations altogether.

4

Yes, exactly, because if you call it from a Python task, you still create a sync point where the GIL is grabbed at the beginning and the end of the task.