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.

Sign up for GitHub

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

Jump to bottom

Cancellation shouldn't need a synchronized primitive #209

Open
mdickinson opened this issue Sep 22, 2020 · 1 comment
Open

Cancellation shouldn't need a synchronized primitive #209

mdickinson opened this issue Sep 22, 2020 · 1 comment
Labels
type: refactor Cleanup or refactoring tasks that don't add functionality or fix bugs

Comments

@mdickinson
Copy link
Member

Right now cancellation uses an event (e.g., a threading.Event in the common case, or a multiprocessing.Event for the in-progress multiprocessing work). That event is synchronized, and that level of synchronization is unnecessary. All we should need here is a signal sent from the foreground to the background.
@mdickinson mdickinson added this to the Release 0.3.0 milestone Sep 22, 2020
@mdickinson mdickinson added the type: enhancement New feature or request label Sep 23, 2020
@mdickinson mdickinson added type: refactor Cleanup or refactoring tasks that don't add functionality or fix bugs and removed type: enhancement New feature or request labels Mar 27, 2021
@mdickinson
Copy link
Member Author

Not valuable for the next release. Removing from the milestone.

@mdickinson mdickinson removed this from the Release 0.3.0 milestone Mar 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: refactor Cleanup or refactoring tasks that don't add functionality or fix bugs
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mdickinson