bpo-44145: Release the GIL around HMAC_Update. (GH-26157)

It was always meant to be released for parallelization.
This now matches the other similar code in the module.

Thanks michaelforney for noticing!
(cherry picked from commit c10392e7ddb3eafbd11e9ffe335c07648426715f)

Co-authored-by: Gregory P. Smith <greg@krypto.org>

diff --git a/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst b/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst
new file mode 100644 (file)
index 0000000..4022218
--- /dev/null
+++ b/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst
@@ -0,0 +1,3 @@
+:mod:`hmac` computations were not releasing the GIL while calling the
+OpenSSL ``HMAC_Update`` C API (a new feature in 3.9).  This unintentionally
+prevented parallel computation as other :mod:`hashlib` algorithms support.

diff --git a/Modules/_hashopenssl.c b/Modules/_hashopenssl.c
index e4a28853775672f8b1da0f1c182b7177ce5af6bb..b9e68c05c3edbeec2d1d75f1f19333a2ffcf4f54 100644 (file)
--- a/Modules/_hashopenssl.c
+++ b/Modules/_hashopenssl.c
@@ -1496,9 +1496,11 @@ _hmac_update(HMACobject *self, PyObject *obj)
     }
 
     if (self->lock != NULL) {
-        ENTER_HASHLIB(self);
+        Py_BEGIN_ALLOW_THREADS
+        PyThread_acquire_lock(self->lock, 1);
         r = HMAC_Update(self->ctx, (const unsigned char*)view.buf, view.len);
-        LEAVE_HASHLIB(self);
+        PyThread_release_lock(self->lock);
+        Py_END_ALLOW_THREADS
     } else {
         r = HMAC_Update(self->ctx, (const unsigned char*)view.buf, view.len);
     }