Skip to content

Conversation

@ghost
Copy link

@ghost ghost commented Sep 7, 2020

Setting `next_in` before acquiring the thread lock may mix up compress/decompress state in other threads.
@iritkatriel
Copy link
Member

backporting to branches other than master is automated, you don't need to create additional PRs for that.

@ghost
Copy link
Author

ghost commented Sep 7, 2020

backporting to branches other than master is automated, you don't need to create additional PRs for that.

There is a code conflict, a few hours ago zlib module was changed by another issue.

@iritkatriel
Copy link
Member

What I mean is that you shouldn't have created this PR and 22132. You only needed to create PR 22126. When a core reviewer approves PR 22126 they can choose to back port the change to other branches. They have buttons that do this.

So you only make PRs against master branch. Core reviewers backport them.

@ghost
Copy link
Author

ghost commented Sep 19, 2020

There is a code confilct, this line was added to master branch recently:

zlibstate *state = PyType_GetModuleState(cls);

@ambv ambv merged commit ba7338a into python:3.9 Apr 26, 2021
@bedevere-bot
Copy link

@ambv: Please replace # with GH- in the commit message next time. Thanks!

@ghost ghost deleted the thread_lock_3.9 branch April 27, 2021 00:45
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.

5 participants