While working on https://github.com/learningequality/kolibri-installer-android/pull/119 it became apparent that when multiple tasks are run simultaneously on Android, that they can interfere with each other. This would happen because of the basic assumption built into Python for Android that within any process there was only a single thread using the Python interpreter. So far to address this, the following changes have been made in our fork of P4A and in the code in this repository:
No longer calling the Python C API PyFinalize method when a python script has finished executing in the WorkManager context
No longer setting the special service class created for WorkManager to tear down with the task (which could cause errors to occur when two tasks are running and one got cleaned up).
There was an experiment that counted the number of active Python threads in the process and then called PyFinalize when it dropped to zero, but this seemed to cause issues when the Python interpreter was reinitialized - specifically, that the PyJnius imports from its pyi files (which provide the interface to Java) would result in something being not found.
Ultimately, it seems like in spite of the above attempts, the PyJnius error does persist - with some indications that even without an explicit teardown of the Python interpreter, it might be being garbage collected to free up memory when no tasks are running. What would be helpful in this case then is to ensure that the service is properly exited, to call System.exit in the process and cause it to be closed, thus emulating some of the prior defensive behaviour put in place in P4A and subsequent WorkManager integration work.
While working on https://github.com/learningequality/kolibri-installer-android/pull/119 it became apparent that when multiple tasks are run simultaneously on Android, that they can interfere with each other. This would happen because of the basic assumption built into Python for Android that within any process there was only a single thread using the Python interpreter. So far to address this, the following changes have been made in our fork of P4A and in the code in this repository:
PyFinalizemethod when a python script has finished executing in the WorkManager contextPyFinalizewhen it dropped to zero, but this seemed to cause issues when the Python interpreter was reinitialized - specifically, that the PyJnius imports from its pyi files (which provide the interface to Java) would result in something being not found.Ultimately, it seems like in spite of the above attempts, the PyJnius error does persist - with some indications that even without an explicit teardown of the Python interpreter, it might be being garbage collected to free up memory when no tasks are running. What would be helpful in this case then is to ensure that the service is properly exited, to call
System.exitin the process and cause it to be closed, thus emulating some of the prior defensive behaviour put in place in P4A and subsequent WorkManager integration work.