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

Do not busy wait in Python. #3892

Merged
merged 2 commits into from
Feb 7, 2020
Merged

Do not busy wait in Python. #3892

merged 2 commits into from
Feb 7, 2020

Conversation

pgavlin
Copy link
Member

@pgavlin pgavlin commented Feb 7, 2020

Instead, keep a stack of outstanding RPCs and await each in turn. This
allows the main loop to block instead of spin.

Fixes #3759.

Instead, keep a stack of outstanding RPCs and await each in turn. This
allows the main loop to block instead of spin.

Fixes #3759.
Copy link
Contributor

@EvanBoyle EvanBoyle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@pgavlin pgavlin merged commit 4a201a7 into master Feb 7, 2020
@pulumi-bot pulumi-bot deleted the pgavlin/pyWait branch February 7, 2020 20:11
joeduffy added a commit that referenced this pull request Dec 31, 2021
If the last line printed to stdout or stderr was missing a
terminating newline, it would go entirely missing (in all languages).
The reason for this is a bug in the engine's handling of plugin
outputs: Go's Reader.ReadString('\n') returns a string containing what
was read and/or an error; if the string terminated in a '\n', the
error is nil, and the entire line is returned; if the stream ends,
however, a non-nil error is returned *and* what was read is returned,
even though it wasn't terminated in a newline. The fix is simple:
instead of ignoring that text, we use it, and *then* exit the read-loop.

Also added some test cases since this is subtle and easy to regress.
joeduffy added a commit that referenced this pull request Dec 31, 2021
If the last line printed to stdout or stderr was missing a
terminating newline, it would go entirely missing (in all languages).
The reason for this is a bug in the engine's handling of plugin
outputs: Go's Reader.ReadString('\n') returns a string containing what
was read and/or an error; if the string terminated in a '\n', the
error is nil, and the entire line is returned; if the stream ends,
however, a non-nil error is returned *and* what was read is returned,
even though it wasn't terminated in a newline. The fix is simple:
instead of ignoring that text, we use it, and *then* exit the read-loop.

Also added some test cases since this is subtle and easy to regress.
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.

100% CPU usage while waiting for EKS cluster creation
3 participants