[HZ-5434] FencedLock for Asyncio#818
Conversation
# Conflicts: # hazelcast/internal/asyncio_client.py
# Conflicts: # hazelcast/asyncio/__init__.py
# Conflicts: # hazelcast/asyncio/__init__.py
# Conflicts: # hazelcast/asyncio/__init__.py # hazelcast/internal/asyncio_proxy/cp_manager.py
# Conflicts: # hazelcast/asyncio/__init__.py # hazelcast/internal/asyncio_proxy/cp_manager.py
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #818 +/- ##
==========================================
- Coverage 94.18% 94.10% -0.08%
==========================================
Files 411 412 +1
Lines 27513 27686 +173
==========================================
+ Hits 25912 26054 +142
- Misses 1601 1632 +31 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
How are you going to protect lock ownership without thread id? There will be concurrent runs, right? |
The lock is reentrant for lock attempts with the same client, similar to the Node.js client, so data races will happen with operations that uses the same client. |
|
The SSL tests with Python 3.13 + Windows fail, but that's unrelated to this PR. |
Ported
FencedLockproxy to asyncio.The asyncore variant uses actual thread IDs to disable re-entrancy.
That's not useful with the asyncio variant, so currently the thread ID
0is used when necessary.I've omitted docs that refer to threads, and tests that use threads.
I'll push another PR to add those after lock context implementation.