8000 Remove threading patches and don't remove multiprocessing module by rth · Pull Request #796 · pyodide/pyodide · GitHub
[go: up one dir, main page]

Skip to content

Remove threading patches and don't remove multiprocessing module #796

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

Merged
merged 4 commits into from
Nov 22, 2020

Conversation

rth
Copy link
Member
@rth rth commented Nov 11, 2020

Related to #144

We currently patch included packages to replace threading by dummy_threading imports. Also multiprocessing module is removed (and so fails to import), requiring us to patch any package that uses it.

In this PR,

  • I remove all patches that replace threading by dummy_threading. Using dummy_threading will lead to deadlocks when thread communication is expected, while objects like threading.RLlock, threading.Lock are actually working fine. When threading.Thread(..).start() is called it will produce a "can't start new thread" exception which I think is a reasonable message in the context of pyodide.
    If the use of dummy_threading is desired it can be monkeypatched globally at run time cf Handling unsupported CPython stdlib modules #144 (comment)
  • The multiprocessing module is no longer removed, so it will import without error. Surprisingly multiprocessing.cpu_count() returns 16 (maybe that is hard-coded in emscripten?). Starting a new Process will raise a Resource temporarily unavailable exception, while calling os.fork() which I think is also reasonable.

Overall the goal is to noticeably reduce the amount of patches we have to maintain, and also support more packages from PyPi with micropip without requiring patches.

I added tests to checks the above mentioned behavior. This also adds a few test improvements with a more systematic use of pytest.raises when needed.

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 this pull request may close these issues.

1 participant
0