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

[Refcator] Extract message types as MessageType Enum in ProcessEnvironment #938

Merged
merged 1 commit into from
Jul 21, 2021

Conversation

breakds
Copy link
Contributor

@breakds breakds commented Jul 19, 2021

This is a refactor, which means that no logic is being changed.

Motivation

This is part of the effort to address #913. A sub-task requires extract the worker logic to be out of the class (for some reason it will prevent multiprocessing to work correctly). Without such change the multiprocessing.Process will just be stuck on start().

This is part of the effort to address #913. A sub-task requires extract the worker logic to be out of the class (for some reason it will prevent `multiprocessing` to work correctly). Without such change the `multiprocessing.Process` will just be stuck on `start()`.
@breakds breakds merged commit d1d1cc6 into pytorch Jul 21, 2021
@breakds breakds deleted the PR_extract_message_type branch July 21, 2021 22:35
@emailweixu
Copy link
Contributor

This is a refactor, which means that no logic is being changed.

Motivation

This is part of the effort to address #913. A sub-task requires extract the worker logic to be out of the class (for some reason it will prevent multiprocessing to work correctly). Without such change the multiprocessing.Process will just be stuck on start().

How does this change solve the problem of stucking on start()?

@breakds
Copy link
Contributor Author

breakds commented Jul 22, 2021

This is a refactor, which means that no logic is being changed.

Motivation

This is part of the effort to address #913. A sub-task requires extract the worker logic to be out of the class (for some reason it will prevent multiprocessing to work correctly). Without such change the multiprocessing.Process will just be stuck on start().

How does this change solve the problem of stucking on start()?

I do not know why as well, this is just an observation. My guess is that without passing self the multiprocessing do not have to pickle the ProcessEnvironment itself, which might be triggering something that contribute to the "getting stuck" problem.

pd-perry pushed a commit to pd-perry/alf that referenced this pull request Dec 11, 2021
…zonRobotics#938)

This is part of the effort to address HorizonRobotics#913. A sub-task requires extract the worker logic to be out of the class (for some reason it will prevent `multiprocessing` to work correctly). Without such change the `multiprocessing.Process` will just be stuck on `start()`.
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.

3 participants