-
Notifications
You must be signed in to change notification settings - Fork 192
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
[Windows, Mac] Can't use call_if_inside/call_if_not_inside matcher decorators with multiprocessing #1181
Comments
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 2, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 3, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
changed the title
[Windows, Mac, Linux in future] Can't use call_if_inside/call_if_not_inside matcher decorators with multiprocessing
[Windows, Mac] Can't use call_if_inside/call_if_not_inside matcher decorators with multiprocessing
Sep 3, 2024
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 3, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 4, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 4, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 4, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
kiri11
added a commit
to kiri11/LibCST
that referenced
this issue
Sep 4, 2024
To support multiprocessing on Windows/macOS Issue Instagram#1181
I decided to go with the second approach (delayed initialization). Matchers are populated right before we need them, so they will end up in the same process. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue has been reported before (#848, #629, #435), but I debugged it and found the root cause, so decided to create another one with more information.
Example traceback:
Root cause
The matchers are dataclasses with
__hash__
method returning theirid
. Theirid
changes in every process, so we can't compare their instances created in different processes.Even though the same matcher was added to
all_matchers
, this was when transformer/visitor initialized in the main process. The check causing exception happens in the child process, which has its own copy of all matchers with another set of ids.This might work on Linux because it uses
fork()
for multiprocessing by default.But Windows and MacOS use
spawn()
with a fresh Python interpreter in each child process.And it will break even on Linux in Python 3.14+ when Python changes the default way to start child processes in Linux.
The issue does not happen with
leave
/visit
matcher decorators, because they are only used withmatches
, never compared directly.Potential solutions
_cli.py
can re-initialize_matchers
of theMatcherDecoratable
transformer/visitor in each child process. Most straightforward way and easy to implement. MatcherDecoratable class can have a function just for that. But every other caller must know to do that in the multiprocessing context.Make
MatcherDecoratableTransformer
/MatcherDecoratableVisitor
multiprocessing-safe, but how? Maybe delayed initialization of_matchers
? But it could still be accessed before the spawn. Or maybe it could save the pid with which matchers were initialized and re-initialize them if pid changes? Seems complicated.Another way that I don't see? Open for discussion.
The text was updated successfully, but these errors were encountered: