[CLIENT-3146] Add support for free threading mode in Python 3.13 #686
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #686 +/- ##
==========================================
+ Coverage 80.89% 81.02% +0.12%
==========================================
Files 100 100
Lines 15053 15081 +28
==========================================
+ Hits 12177 12219 +42
+ Misses 2876 2862 -14
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
juliannguyen4
force-pushed
the
CLIENT-3146-free-threading
branch
from
04fd5f2
to
2ea9a9a
Compare
juliannguyen4
force-pushed
the
CLIENT-3146-free-threading
branch
from
0d89565
to
3234a03
Compare
| client = aerospike.client(config) | ||
| _, _, bins = client.get(key) | ||
| nonlocal bin_value_sum | ||
| lock.acquire() |
There was a problem hiding this comment.
You shouldn't have an unnecessary lock here during the read_bin(). You can simply verify by doing something like the following:
-
in the test phase, have your base action be to update a record so the bin value changes from x to x + 1
-
in verification phase, sum the value of all bins you changed before and after the test. The difference should be the number of operations you submitted.
The key here is that you don't require locking during the submission of the updates
| @pytest.mark.usefixtures("as_connection") | ||
| class TestFreeThreading: | ||
| def test_unsafe(self): | ||
| key = ("test", "demo", 1) |
There was a problem hiding this comment.
Probably not a great idea to only use one key - you should generate a bunch of keys - the number of keys / number of operations will give you the basic collision rate.
| for worker in workers: | ||
| worker.join() | ||
|
|
||
| assert bin_value_sum == THREAD_COUNT * BIN_VALUE |
There was a problem hiding this comment.
I would also report out to a log the timing so you can calculate and report out basic throughput numbers. You can use this to sanity check to see if you get better numbers with a large transaction count, multiple threads running with and without GIL.
There was a problem hiding this comment.
Maybe it would be good to have both performance and data race testing?
This reverts commit dd38370.
todo: