Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-135239: simpler use of mutex in hashlib & co #135267

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

Open
wants to merge 44 commits into
base: main
Choose a base branch
from

Conversation

picnixz
Copy link
Member

@picnixz picnixz commented Jun 8, 2025

I've taken the liberty of normalizing code style. I'll do the same in other modules, (SHA and BLAKE2). That way, I'll never need to touch cosmetics again in crypto-modules. Well, if it's too much I can drop the last commit.

Copy link
Member

@ZeroIntensity ZeroIntensity left a comment

Choose a reason for hiding this comment

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

Note that PyMutex_Lock will release the GIL/detach the thread state anyway. You want _PyMutex_LockFlags(m, _Py_LOCK_DONT_DETACH) if you're worried about GIL overhead.

@picnixz picnixz marked this pull request as draft June 8, 2025 19:37
@picnixz picnixz requested a review from ZeroIntensity June 15, 2025 09:40
@picnixz picnixz marked this pull request as ready for review June 15, 2025 11:39
@picnixz picnixz marked this pull request as draft June 16, 2025 10:16
@picnixz picnixz force-pushed the perf/hashlib/mutex-135239 branch from bb237c2 to db57278 Compare June 16, 2025 10:35
@ZeroIntensity
Copy link
Member

Ok, so we're actually losing speed because of Py_BEGIN_ALLOW_THREADS. However, without those calls, we could end up being blocked by the update call itself, right? Thus, I'll restore the check for large buffers, and only release the GIL when the buffers are really large (but I'll still lock the object itself).

That sounds fine to me, but make sure that the locking is done in a consistent order. Note that acquiring the lock will release the GIL, unless you explicitly tell it not to with _Py_LOCK_DONT_DETACH.

@picnixz picnixz requested a review from vstinner June 20, 2025 09:41
@picnixz picnixz marked this pull request as draft June 21, 2025 12:36
@picnixz

This comment was marked as resolved.

@picnixz picnixz marked this pull request as ready for review June 21, 2025 13:46
@picnixz

This comment was marked as resolved.

@picnixz

This comment was marked as resolved.

@bedevere-bot

This comment was marked as resolved.

@picnixz

This comment was marked as resolved.

@bedevere-bot

This comment was marked as resolved.

@picnixz
Copy link
Member Author

picnixz commented Jun 21, 2025

I'll check performance tomorrow. The (full) tests are much slower now but that's because I'm testing all known hash functions, whereas before, we only tested SHA-1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting core review skip news type-refactor Code refactoring (with no changes in behavior)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants