Conversation
…upport a parameterized module name
…ed on free-threading builds
…is always unlocked
PYXXH32_update, PYXXH64_update, PYXXH3_64_update and PYXXH3_128_update were identical except for type prefixes and algorithm names. The new macro eliminates all four bodies, saving 148 lines.
ifduyue
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request optimizes performance by making the default streaming hash objects in xxhash non-thread-safe by default, removing per-object locking overhead. A new xxhash.threadsafe submodule is introduced to provide thread-safe streaming hash objects with per-object locks. The C extension src/_xxhash.c is refactored to support compiling both variants (_xxhash and _xxhash_threadsafe) from the same source, and setup.py is updated to build both extensions. Additionally, the deprecated VERSION_TUPLE is removed, and the package version is bumped to 4.0.0.dev0. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Merging this PR will not alter performance
Comparing 
Footnotes
|
…eclarations The stub file xxhash/__init__.pyi incorrectly defined xxh64_digest, xxh64_hexdigest, xxh64_intdigest as aliases of xxh3_64_* functions. xxh64 and xxh3_64 are separate algorithms with potentially different hash outputs, so they should have independent function declarations. This aligns with the already-correct threadsafe.pyi.
The previous lazy allocation in XXHASH_LOCK_MAYBE_INIT only created a PyThread_type_lock if update() was called with data >= 64KB. This meant that if a thread-safe hash object was only used with small data (or never called update()), digest(), copy(), reset(), etc. all ran without any synchronization because XXHASH_LOCK_ACQUIRE was a no-op when lock == NULL. Fix: always allocate the lock at initialization via XXHASH_LOCK_INIT, matching hashlib's approach of always-initialized mutex (HASHLIB_INIT_MUTEX). This eliminates the security window entirely. Changes: - XXHASH_LOCK_INIT now calls PyThread_allocate_lock() instead of setting NULL - XXHASH_LOCK_MAYBE_INIT reduced to a no-op (lock always allocated) - Simplified _do_update by removing the lazy init call and dead 'no lock' branch - locking is now unconditional (no-op in non-lock build) - NULL guards in acquire/release/fini retained as defensive safety Python 3.13+ (PyMutex path) was not affected as it was already always-on.
…RUCTIONS_LOCKED
Two changes:
1. Simplify lock macros to match 3.15's unconditional acquire/release:
- PyMutex path (3.13+): retain only FIELD/INIT/FINI/ACQUIRE/RELEASE;
remove IS_ACTIVE, MAYBE_INIT, ACQUIRE_BLOCKING (no longer needed)
- PyThread_type_lock path (3.9-3.12): ACQUIRE/RELEASE are now
unconditional blocking calls (no NULL guards, no try-then-block),
matching 3.15's HASHLIB_ACQUIRE_LOCK
- Non-lock path: keep only mandatory macros
2. Simplify _do_update to 3.15's pattern:
- Both large and small data paths use the SAME XXHASH_LOCK_ACQUIRE
- Size threshold (XXHASH_GIL_MINSIZE) only controls GIL release,
NOT whether locking happens
- Matches 3.15's HASHLIB_EXTERNAL_INSTRUCTIONS_LOCKED exactly
…k under GIL 4443f28 incorrectly simplified the 3.9-3.12 PyThread_type_lock path to unconditional WAIT_LOCK. This is unsafe under GIL: PyThread_acquire_lock(lock, WAIT_LOCK) does NOT release the GIL while waiting, unlike PyMutex_Lock (3.13+) which passes _PY_LOCK_DETACH and releases GIL when parking. Deadlock scenario: 1. T1 holds object lock (large data path, GIL released) 2. T2 holds GIL, enters small data path, calls WAIT_LOCK → blocks with GIL 3. T1 finishes hash, tries to reacquire GIL → blocked 4. T2 waits for object lock, T1 waits for GIL → deadlock Fix: restore the try-then-block in XXHASH_LOCK_ACQUIRE (used under GIL): - First try NOWAIT_LOCK (fast path) - If contested, release GIL (Py_BEGIN_ALLOW_THREADS), then WAIT_LOCK - Reacquire GIL (Py_END_ALLOW_THREADS) XXHASH_LOCK_ACQUIRE_BLOCKING (used without GIL, large data path) keeps simple WAIT_LOCK since GIL is already released. 3.13+ PyMutex path remains unconditional (safe due to _PY_LOCK_DETACH).
1 participant
Uh oh!
There was an error while loading. Please reload this page.