-
-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Objective is to claim compatibility with free-threaded builds, but not (yet..?) promise thread-safety of the API and classes.
Edited ChatGPT suggestions for tests:
-
A “GIL stays off” smoke test
Add a test that runs in a free-threaded interpreter and checks the runtime GIL state before/after import:
assert sys._is_gil_enabled() is False early in the process import sphobjinv assert sys._is_gil_enabled() is False after import
This catches the “a dependency re-enabled the GIL” class quickly.
Python Free-Threading Guide -
Multithreaded stress tests around your public API
Even if sphobjinv itself doesn’t create threads, your users might. Add a small set of tests that:
-
start (say) 8–32 threads
-
repeatedly do parse → inspect → serialize cycles on inventories
-
use separate temp dirs/files per thread (so you’re not testing filesystem collisions unless you want to)
What you’re looking for is: crashes, hangs, corrupted outputs, nondeterministic exceptions.
Why: global caches / module globals / shared singletons are the number one problem in pure-Python packages.
-
-
Run the same multithread tests on the regular build with an ultra-low switch interval
The guide suggests using a very short thread switch interval to flush out thread bugs even on the GIL build.
So: in that threaded test module, set something like
sys.setswitchinterval(1e-6)(and restore after). This often makes racy code fail faster. -
A “shared object misuse” test (optional but valuable)
Decide what you want to support, then test it explicitly:
-
If you don’t want to promise that a single
Inventoryinstance is safe to mutate from multiple threads, document that and only test “separate instances per thread.” -
If you do want to support it, add a test that shares one instance across threads while performing read-only operations (and possibly controlled mutations), and assert consistency.
-
-
Property-based / fuzz testing for determinism under concurrency (nice payoff)
For a tool like sphobjinv, it’s natural to test invariants such as:
-
decode(encode(inv)) round-trips
-
string/JSON outputs parse back to the same semantic inventory
Run those invariants under a thread pool to catch “rare” races.
-