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

[picnixz]

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.

• Issue: Smarter use of a mutex in incremental HMAC and hash functions #135239

[ZeroIntensity]

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]

I think we're good now. I'm leaving my dev session and won't be back until Thursday so this will need to wait.

[ZeroIntensity]

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]

huh, the tests are becoming slower, something went wrong with my update

[picnixz]

Ok I've removed the renaming. I'll do it in a follow-up because it's easier that way (and it's not even mandatory, I only renamed one function because the name was misleading).

[picnixz]

!buildbot FIPS only

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @picnixz for commit 98ec915 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F135267%2Fmerge

The command will test the builders whose names match following regular expression: FIPS only

The builders matched are:

• AMD64 RHEL8 FIPS Only Blake2 Builtin Hash PR
• AMD64 CentOS9 FIPS Only Blake2 Builtin Hash PR