Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure the task environment does not improperly cleanup the Python interpreter #132

Closed
rtibbles opened this issue Apr 17, 2023 · 0 comments · Fixed by #145
Closed

Ensure the task environment does not improperly cleanup the Python interpreter #132

rtibbles opened this issue Apr 17, 2023 · 0 comments · Fixed by #145
Assignees

Comments

@rtibbles
Copy link
Member

While working on #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
  • Registering against the Global Interpreter Lock using the Python C API as recommended here: https://docs.python.org/3/c-api/init.html#non-python-created-threads
  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant