From c10392e7ddb3eafbd11e9ffe335c07648426715f Mon Sep 17 00:00:00 2001 From: "Gregory P. Smith" Date: Mon, 17 May 2021 00:35:16 -0700 Subject: 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! --- Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst | 3 +++ Modules/_hashopenssl.c | 6 ++++-- 2 files changed, 7 insertions(+), 2 deletions(-) create mode 100644 Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst 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 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 e4a2885..b9e68c0 100644 --- 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); } -- cgit v0.12