Some multiprocessing APIs should be possible to import or use even when multiprocessing itself isn't available #134634
Labels
Comments
terryjreedy
added
type-feature
|
(EDIT) I have no idea is these changed would be acceptible. In any case, we cannot/will-not grab other people's code. Someone with 'ownership' of chaquopy would have to sign our Contributor Licensing Agreement and submit a PR with their code. Or someone else (you?) would have to write new code that does not violate their copyright. |
|
@terryjreedy FTR: @mhsmith is the founder and principal author of Chaquopy. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
Android doesn't support multiprocessing because it doesn't support the System V IPC API, and iOS doesn't support subprocesses at all. However, there are a couple of things that should still work on these platforms, but currently don't:
multiprocessing.dummy.Pool(akamultiprocessing.pool.ThreadPool) currently depends on themultiprocessingsynchronization primitives, when it could use thethreadingequivalents instead.multiprocessing.synchronizethrows an exception on import if the synchronization primitives are unavailable. But this breaks some packages like joblib, which imports the primitives but doesn't always use them (joblib/joblib#825).Chaquopy has some monkey patches to work around these issues, but it would be better if they were fixed upstream.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Other
The text was updated successfully, but these errors were encountered: