PyPcre 0.3.1__tar.gz → 0.4.0__tar.gz

{pypcre-0.3.1 → pypcre-0.4.0}/PKG-INFO

@@ -1,9 +1,9 @@
 Metadata-Version: 2.4
 Name: PyPcre
-Version: 0.3.1
+Version: 0.4.0
 Summary: Modern, GIL-friendly, Fast Python bindings for PCRE2 with auto caching and JIT of compiled patterns.
 Author-email: ModelCloud <qubitium@modelcloud.ai>
-License: Apache-2.0
+License-Expression: Apache-2.0
 Project-URL: Homepage, https://github.com/ModelCloud/pcre
 Keywords: regex,pcre2,bindings
 Classifier: Programming Language :: Python :: 3
@@ -47,6 +47,7 @@ Fast, free-threaded Python bindings for `PCRE2` with a stable `stdlib.re`-compat
 
 
 ## Latest News 🚀
+* 07/24/2026 [0.4.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.4.0): C extension hardening (memory/pointer safety, bounds checks, atomic allocator init), GIL=0 safety verified, vectorized UTF-8 index/offset conversion, GIL-release threshold for small calls, C `findall` implementation, and README competitor benchmarks. 🛡️⚡
 * 04/13/2026 [0.3.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.3.0): Lower-overhead public `Match` objects, faster hot-path `match()` / `search()` / `fullmatch()` / `findall()`, and tighter free-threaded execution. ⚡
 * 03/22/2026 [0.2.15](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.15): Python 3.15 `re` compatibility (`prefixmatch`, `NOFLAG`) ✅
 * 03/21/2026 [0.2.14](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.14): Python 3.14 compatibility 🐍
@@ -85,26 +86,44 @@ PyPcre pairs Python's familiar `re`-compatible API with the real `PCRE2` engine.
 
 ### Benchmark Highlights 🏁
 
-Measured on a `Python 3.14.3` free-threaded build on x86_64 Linux with compiled-pattern reuse. Times are best-of-5; lower is better.
+Measured on a `Python 3.14.5` free-threaded build on x86_64 Linux with compiled-pattern reuse and JIT enabled. Times are the best of several runs; lower is better. Only workloads where PyPcre is decisively faster than both `stdlib.re` and `regex` are shown.
 
-| Workload | Operation | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | --- | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `search` | `3.68 ms` | `51.72 ms` | `5.67 ms` | `14.0x` vs `re`, `1.54x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `findall` | `6.41 ms` | `91.84 ms` | `91.14 ms` | `14.3x` vs `re`, `14.2x` vs `regex` |
-| Per-line full-name extraction | `findall` | `22.28 ms` | `172.38 ms` | `218.29 ms` | `7.74x` vs `re`, `9.80x` vs `regex` |
-| Lookbehind + negative-lookahead extraction | `findall` | `50.23 ms` | `53.35 ms` | `57.03 ms` | `1.06x` vs `re`, `1.14x` vs `regex` |
-| UUID extraction | `findall` | `77.49 ms` | `83.19 ms` | `134.87 ms` | `1.07x` vs `re`, `1.74x` vs `regex` |
-| Boundary-aware token scan | `findall` | `127.76 ms` | `128.03 ms` | `146.37 ms` | effectively tied with `re`, `1.15x` vs `regex` |
+A reproducible version of this benchmark lives in [`benchmarks/competitor_bench.py`](benchmarks/competitor_bench.py).
+
+#### `findall` — large multiline and lookaround workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (multiline) | `0.60` | `29.35` | `30.85` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction (multiline) | `1.02` | `29.50` | `15.95` | **29x** vs `re`, **16x** vs `regex` |
+| Lookbehind + negative-lookahead tokens | `3.78` | `11.81` | `10.42` | **3.1x** vs `re`, **2.8x** vs `regex` |
+
+Patterns used:
+
+```python
+# WARN/ERROR lines and full-name extraction
+^(?:WARN|ERROR).*?$        # with re.MULTILINE / pcre.Flag.MULTILINE
+^[A-Z][a-z]+ [A-Z][a-z]+   # with re.MULTILINE / pcre.Flag.MULTILINE
+
+# lookbehind + negative lookahead
+(?:(?<=foo)bar|baz)(?!qux)
+```
+
+#### `finditer` — same workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines | `0.60` | `29.33` | `31.23` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction | `1.02` | `30.09` | `16.25` | **29x** vs `re`, **16x** vs `regex` |
 
 ### Free-Threaded Benchmark Highlights 🧵
 
-Measured in the same environment with `8` threads sharing one compiled pattern. Times are best-of-3; lower is better.
+Measured in the same environment with `8` threads fanning out over independent copies of each workload. Times are the best of several runs; lower is better.
 
-| Workload | Threads | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | ---: | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `8` | `25.34 ms` | `38.83 ms` | `40.34 ms` | `1.53x` vs `re`, `1.59x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `8` | `28.58 ms` | `65.54 ms` | `73.55 ms` | `2.29x` vs `re`, `2.57x` vs `regex` |
-| Per-line full-name extraction | `8` | `31.68 ms` | `123.44 ms` | `164.80 ms` | `3.90x` vs `re`, `5.20x` vs `regex` |
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (`findall`) | `3.26` | `32.57` | `34.41` | **10.0x** vs `re`, **10.6x** vs `regex` |
+| Per-line full-name extraction (`findall`) | `3.18` | `31.84` | `17.31` | **10.0x** vs `re`, **5.4x** vs `regex` |
 
 PyPcre is the stronger all-around choice when you want more than the baseline: full `PCRE2` features, more expressive syntax, JIT, explicit free-threaded support, and a stable `re`-compatible API surface. It keeps Python ergonomics while giving you a substantially more capable engine. 🚀
 

{pypcre-0.3.1 → pypcre-0.4.0}/PyPcre.egg-info/PKG-INFO

@@ -1,9 +1,9 @@
 Metadata-Version: 2.4
 Name: PyPcre
-Version: 0.3.1
+Version: 0.4.0
 Summary: Modern, GIL-friendly, Fast Python bindings for PCRE2 with auto caching and JIT of compiled patterns.
 Author-email: ModelCloud <qubitium@modelcloud.ai>
-License: Apache-2.0
+License-Expression: Apache-2.0
 Project-URL: Homepage, https://github.com/ModelCloud/pcre
 Keywords: regex,pcre2,bindings
 Classifier: Programming Language :: Python :: 3
@@ -47,6 +47,7 @@ Fast, free-threaded Python bindings for `PCRE2` with a stable `stdlib.re`-compat
 
 
 ## Latest News 🚀
+* 07/24/2026 [0.4.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.4.0): C extension hardening (memory/pointer safety, bounds checks, atomic allocator init), GIL=0 safety verified, vectorized UTF-8 index/offset conversion, GIL-release threshold for small calls, C `findall` implementation, and README competitor benchmarks. 🛡️⚡
 * 04/13/2026 [0.3.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.3.0): Lower-overhead public `Match` objects, faster hot-path `match()` / `search()` / `fullmatch()` / `findall()`, and tighter free-threaded execution. ⚡
 * 03/22/2026 [0.2.15](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.15): Python 3.15 `re` compatibility (`prefixmatch`, `NOFLAG`) ✅
 * 03/21/2026 [0.2.14](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.14): Python 3.14 compatibility 🐍
@@ -85,26 +86,44 @@ PyPcre pairs Python's familiar `re`-compatible API with the real `PCRE2` engine.
 
 ### Benchmark Highlights 🏁
 
-Measured on a `Python 3.14.3` free-threaded build on x86_64 Linux with compiled-pattern reuse. Times are best-of-5; lower is better.
+Measured on a `Python 3.14.5` free-threaded build on x86_64 Linux with compiled-pattern reuse and JIT enabled. Times are the best of several runs; lower is better. Only workloads where PyPcre is decisively faster than both `stdlib.re` and `regex` are shown.
 
-| Workload | Operation | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | --- | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `search` | `3.68 ms` | `51.72 ms` | `5.67 ms` | `14.0x` vs `re`, `1.54x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `findall` | `6.41 ms` | `91.84 ms` | `91.14 ms` | `14.3x` vs `re`, `14.2x` vs `regex` |
-| Per-line full-name extraction | `findall` | `22.28 ms` | `172.38 ms` | `218.29 ms` | `7.74x` vs `re`, `9.80x` vs `regex` |
-| Lookbehind + negative-lookahead extraction | `findall` | `50.23 ms` | `53.35 ms` | `57.03 ms` | `1.06x` vs `re`, `1.14x` vs `regex` |
-| UUID extraction | `findall` | `77.49 ms` | `83.19 ms` | `134.87 ms` | `1.07x` vs `re`, `1.74x` vs `regex` |
-| Boundary-aware token scan | `findall` | `127.76 ms` | `128.03 ms` | `146.37 ms` | effectively tied with `re`, `1.15x` vs `regex` |
+A reproducible version of this benchmark lives in [`benchmarks/competitor_bench.py`](benchmarks/competitor_bench.py).
+
+#### `findall` — large multiline and lookaround workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (multiline) | `0.60` | `29.35` | `30.85` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction (multiline) | `1.02` | `29.50` | `15.95` | **29x** vs `re`, **16x** vs `regex` |
+| Lookbehind + negative-lookahead tokens | `3.78` | `11.81` | `10.42` | **3.1x** vs `re`, **2.8x** vs `regex` |
+
+Patterns used:
+
+```python
+# WARN/ERROR lines and full-name extraction
+^(?:WARN|ERROR).*?$        # with re.MULTILINE / pcre.Flag.MULTILINE
+^[A-Z][a-z]+ [A-Z][a-z]+   # with re.MULTILINE / pcre.Flag.MULTILINE
+
+# lookbehind + negative lookahead
+(?:(?<=foo)bar|baz)(?!qux)
+```
+
+#### `finditer` — same workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines | `0.60` | `29.33` | `31.23` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction | `1.02` | `30.09` | `16.25` | **29x** vs `re`, **16x** vs `regex` |
 
 ### Free-Threaded Benchmark Highlights 🧵
 
-Measured in the same environment with `8` threads sharing one compiled pattern. Times are best-of-3; lower is better.
+Measured in the same environment with `8` threads fanning out over independent copies of each workload. Times are the best of several runs; lower is better.
 
-| Workload | Threads | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | ---: | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `8` | `25.34 ms` | `38.83 ms` | `40.34 ms` | `1.53x` vs `re`, `1.59x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `8` | `28.58 ms` | `65.54 ms` | `73.55 ms` | `2.29x` vs `re`, `2.57x` vs `regex` |
-| Per-line full-name extraction | `8` | `31.68 ms` | `123.44 ms` | `164.80 ms` | `3.90x` vs `re`, `5.20x` vs `regex` |
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (`findall`) | `3.26` | `32.57` | `34.41` | **10.0x** vs `re`, **10.6x** vs `regex` |
+| Per-line full-name extraction (`findall`) | `3.18` | `31.84` | `17.31` | **10.0x** vs `re`, **5.4x** vs `regex` |
 
 PyPcre is the stronger all-around choice when you want more than the baseline: full `PCRE2` features, more expressive syntax, JIT, explicit free-threaded support, and a stable `re`-compatible API surface. It keeps Python ergonomics while giving you a substantially more capable engine. 🚀
 

{pypcre-0.3.1 → pypcre-0.4.0}/PyPcre.egg-info/SOURCES.txt

@@ -35,18 +35,23 @@ tests/test_bench_string.py
 tests/test_benchmark.py
 tests/test_bytes.py
 tests/test_cache.py
+tests/test_cache_global.py
+tests/test_cache_global_inproc.py
 tests/test_clobber.py
 tests/test_clobber_thread.py
 tests/test_core.py
+tests/test_coverage_gaps.py
 tests/test_errors.py
 tests/test_flags.py
 tests/test_jit.py
 tests/test_memory.py
 tests/test_module.py
 tests/test_pattern.py
+tests/test_re_compat.py
 tests/test_setup_utils_multiarch.py
 tests/test_simd.py
 tests/test_threaded_backend.py
+tests/test_threads.py
 tests/test_transformers_regex.py
 tests/test_utf8.py
 tests/test_version.py

{pypcre-0.3.1 → pypcre-0.4.0}/README.md

@@ -24,6 +24,7 @@ Fast, free-threaded Python bindings for `PCRE2` with a stable `stdlib.re`-compat
 
 
 ## Latest News 🚀
+* 07/24/2026 [0.4.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.4.0): C extension hardening (memory/pointer safety, bounds checks, atomic allocator init), GIL=0 safety verified, vectorized UTF-8 index/offset conversion, GIL-release threshold for small calls, C `findall` implementation, and README competitor benchmarks. 🛡️⚡
 * 04/13/2026 [0.3.0](https://github.com/ModelCloud/PyPcre/releases/tag/v0.3.0): Lower-overhead public `Match` objects, faster hot-path `match()` / `search()` / `fullmatch()` / `findall()`, and tighter free-threaded execution. ⚡
 * 03/22/2026 [0.2.15](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.15): Python 3.15 `re` compatibility (`prefixmatch`, `NOFLAG`) ✅
 * 03/21/2026 [0.2.14](https://github.com/ModelCloud/PyPcre/releases/tag/v0.2.14): Python 3.14 compatibility 🐍
@@ -62,26 +63,44 @@ PyPcre pairs Python's familiar `re`-compatible API with the real `PCRE2` engine.
 
 ### Benchmark Highlights 🏁
 
-Measured on a `Python 3.14.3` free-threaded build on x86_64 Linux with compiled-pattern reuse. Times are best-of-5; lower is better.
+Measured on a `Python 3.14.5` free-threaded build on x86_64 Linux with compiled-pattern reuse and JIT enabled. Times are the best of several runs; lower is better. Only workloads where PyPcre is decisively faster than both `stdlib.re` and `regex` are shown.
 
-| Workload | Operation | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | --- | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `search` | `3.68 ms` | `51.72 ms` | `5.67 ms` | `14.0x` vs `re`, `1.54x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `findall` | `6.41 ms` | `91.84 ms` | `91.14 ms` | `14.3x` vs `re`, `14.2x` vs `regex` |
-| Per-line full-name extraction | `findall` | `22.28 ms` | `172.38 ms` | `218.29 ms` | `7.74x` vs `re`, `9.80x` vs `regex` |
-| Lookbehind + negative-lookahead extraction | `findall` | `50.23 ms` | `53.35 ms` | `57.03 ms` | `1.06x` vs `re`, `1.14x` vs `regex` |
-| UUID extraction | `findall` | `77.49 ms` | `83.19 ms` | `134.87 ms` | `1.07x` vs `re`, `1.74x` vs `regex` |
-| Boundary-aware token scan | `findall` | `127.76 ms` | `128.03 ms` | `146.37 ms` | effectively tied with `re`, `1.15x` vs `regex` |
+A reproducible version of this benchmark lives in [`benchmarks/competitor_bench.py`](benchmarks/competitor_bench.py).
+
+#### `findall` — large multiline and lookaround workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (multiline) | `0.60` | `29.35` | `30.85` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction (multiline) | `1.02` | `29.50` | `15.95` | **29x** vs `re`, **16x** vs `regex` |
+| Lookbehind + negative-lookahead tokens | `3.78` | `11.81` | `10.42` | **3.1x** vs `re`, **2.8x** vs `regex` |
+
+Patterns used:
+
+```python
+# WARN/ERROR lines and full-name extraction
+^(?:WARN|ERROR).*?$        # with re.MULTILINE / pcre.Flag.MULTILINE
+^[A-Z][a-z]+ [A-Z][a-z]+   # with re.MULTILINE / pcre.Flag.MULTILINE
+
+# lookbehind + negative lookahead
+(?:(?<=foo)bar|baz)(?!qux)
+```
+
+#### `finditer` — same workloads
+
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines | `0.60` | `29.33` | `31.23` | **49x** vs `re`, **52x** vs `regex` |
+| Per-line full-name extraction | `1.02` | `30.09` | `16.25` | **29x** vs `re`, **16x** vs `regex` |
 
 ### Free-Threaded Benchmark Highlights 🧵
 
-Measured in the same environment with `8` threads sharing one compiled pattern. Times are best-of-3; lower is better.
+Measured in the same environment with `8` threads fanning out over independent copies of each workload. Times are the best of several runs; lower is better.
 
-| Workload | Threads | PyPcre | `re` | `regex` | PyPcre edge |
-| --- | ---: | ---: | ---: | ---: | --- |
-| First `ERROR` line in a multiline log buffer | `8` | `25.34 ms` | `38.83 ms` | `40.34 ms` | `1.53x` vs `re`, `1.59x` vs `regex` |
-| Extract only `WARN` / `ERROR` lines | `8` | `28.58 ms` | `65.54 ms` | `73.55 ms` | `2.29x` vs `re`, `2.57x` vs `regex` |
-| Per-line full-name extraction | `8` | `31.68 ms` | `123.44 ms` | `164.80 ms` | `3.90x` vs `re`, `5.20x` vs `regex` |
+| Workload | PyPcre (ms) | `re` (ms) | `regex` (ms) | PyPcre edge |
+| --- | ---: | ---: | ---: | --- |
+| Extract `WARN` / `ERROR` lines (`findall`) | `3.26` | `32.57` | `34.41` | **10.0x** vs `re`, **10.6x** vs `regex` |
+| Per-line full-name extraction (`findall`) | `3.18` | `31.84` | `17.31` | **10.0x** vs `re`, **5.4x** vs `regex` |
 
 PyPcre is the stronger all-around choice when you want more than the baseline: full `PCRE2` features, more expressive syntax, JIT, explicit free-threaded support, and a stable `re`-compatible API surface. It keeps Python ergonomics while giving you a substantially more capable engine. 🚀
 

{pypcre-0.3.1 → pypcre-0.4.0}/pcre/pcre.py

@@ -386,6 +386,14 @@ class Pattern:
     ) -> List[Any]:
         if type(subject) is memoryview:
             subject = subject.tobytes()
+        backend_findall = getattr(self._pattern, "findall", None)
+        if backend_findall is not None:
+            compiled_end = -1 if endpos is None else resolve_endpos(subject, endpos)
+            try:
+                return backend_findall(subject, pos=pos, endpos=compiled_end, options=options)
+            except TypeError:
+                pass
+
         backend_iter = getattr(self._pattern, "finditer", None)
         if backend_iter is not None:
             compiled_end = -1 if endpos is None else resolve_endpos(subject, endpos)

{pypcre-0.3.1 → pypcre-0.4.0}/pcre_ext/memory.c

@@ -25,7 +25,8 @@ static void *current_handle = NULL;
 static alloc_fn current_alloc = (alloc_fn)PyMem_Malloc;
 static free_fn current_free = (free_fn)PyMem_Free;
 static const char *current_name = "pymem";
-static int allocator_initialized = 0;
+static ATOMIC_VAR(int) allocator_initialized = ATOMIC_VAR_INIT(0);
+static atomic_flag allocator_init_lock = ATOMIC_FLAG_INIT;
 
 #if defined(_WIN32)
 static int
@@ -95,7 +96,19 @@ equals_ignore_case(const char *value, const char *target)
 int
 pcre_memory_initialize(void)
 {
-    if (allocator_initialized) {
+    if (atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
+        return 0;
+    }
+
+    while (atomic_flag_test_and_set_explicit(&allocator_init_lock, memory_order_acq_rel)) {
+        if (atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
+            atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
+            return 0;
+        }
+    }
+
+    if (atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
+        atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
         return 0;
     }
 
@@ -131,7 +144,8 @@ pcre_memory_initialize(void)
         current_alloc = (alloc_fn)PyMem_Malloc;
         current_free = (free_fn)PyMem_Free;
         current_name = "pymem";
-        allocator_initialized = 1;
+        atomic_store_explicit(&allocator_initialized, 1, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
         return 0;
     }
 
@@ -140,18 +154,21 @@ pcre_memory_initialize(void)
         current_alloc = malloc;
         current_free = free;
         current_name = "malloc";
-        allocator_initialized = 1;
+        atomic_store_explicit(&allocator_initialized, 1, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
         return 0;
     }
 
     if (equals_ignore_case(forced, "jemalloc")) {
         if (load_allocator(&jemalloc_candidate) == 0) {
-            allocator_initialized = 1;
+            atomic_store_explicit(&allocator_initialized, 1, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
             return 0;
         }
     } else if (equals_ignore_case(forced, "tcmalloc")) {
         if (load_allocator(&tcmalloc_candidate) == 0) {
-            allocator_initialized = 1;
+            atomic_store_explicit(&allocator_initialized, 1, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
             return 0;
         }
     }
@@ -160,7 +177,8 @@ pcre_memory_initialize(void)
     current_alloc = (alloc_fn)PyMem_Malloc;
     current_free = (free_fn)PyMem_Free;
     current_name = "pymem";
-    allocator_initialized = 1;
+    atomic_store_explicit(&allocator_initialized, 1, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
     return 0;
 }
 
@@ -177,13 +195,14 @@ pcre_memory_teardown(void)
     current_alloc = (alloc_fn)PyMem_Malloc;
     current_free = (free_fn)PyMem_Free;
     current_name = "pymem";
-    allocator_initialized = 0;
+    atomic_store_explicit(&allocator_initialized, 0, memory_order_release);
+    atomic_flag_clear_explicit(&allocator_init_lock, memory_order_release);
 }
 
 void *
 pcre_malloc(size_t size)
 {
-    if (!allocator_initialized) {
+    if (!atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
         if (pcre_memory_initialize() != 0) {
             return NULL;
         }
@@ -197,11 +216,17 @@ pcre_free(void *ptr)
     if (ptr == NULL) {
         return;
     }
+    if (!atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
+        (void)pcre_memory_initialize();
+    }
     current_free(ptr);
 }
 
 const char *
 pcre_memory_allocator_name(void)
 {
+    if (!atomic_load_explicit(&allocator_initialized, memory_order_acquire)) {
+        (void)pcre_memory_initialize();
+    }
     return current_name;
 }