i need to understand gill in practical way. Some of the facts i understood -
it is for reference count of objects
without gil or with gil, still if there is possibility of race condition it will crash or misbehave
no-gill option gives multithreaded support - it is not fully multithreaded is what i understood or no 100% claim it will be multithreaded safe. I mean to say that if there is no race condition issue, it will give 100% performance. (i believe 100% may not be corrrect or 6 to 8 times) and no crash/wrong results. is it correct?
i need to replicate issues or create scripts that will give all sort of possibilities for gil issue. I only put 2 and third is no-gill option. Is there already test scripts available for this - that is main reason i wanted to get on this thread
Some of it i think are reference count mess up will create memory leak and how do we find if there is memory leak? should we use tool like valgrind. There are pyTypeObjects - how to cover all types for gil issue.
The GIL is a OS lock used to prevent multiple threads from corrupting the interpreter state.
Free-threaded python replaces the GIL with other software techniques to prevent multiple threads from corrupting the interpreter. With the advantage that python threads can run in parallel.
Both GIL and free-threaded python are equally thread safe.
However there is thread unsafe code that seems to work with the GIL but can break faster on free-threaded python.
It looks like you’re trying to understand how GIL works. That’s a fairly complex topic, so maybe we can start with a simpler question: are you only writing pure Python, or are you interested in developing CPython / using C (Python C API)?
If you’re only using pure Python, things are much simpler. I’d suggest first take a look at thread safety.
Is there already test scripts available for this
This guide about thread safety is a good starting point for writing tests.
if there is possibility of race condition it will crash
Pure Python code generally won’t crash even on no-GIL build. It’s well protected. Although unexpected behavior may happen if there is a data race.
Some of it i think are reference count mess up will create memory leak
At present no-GIL implementation is fairly mature, so reference-count bugs are quite rare now. But if you do find some, you’are always welcome to report it.
thanks for the link (guide). I am in context cpython and not scripts. But to understand scenaios that can be race condition issue, I asked above and i want to see if i can get possible all kinds of issues. I saw this thread ( Want to understand the significance of GIL and does it replace Mutex Locks? - #3 by nas ) and i asked if with or without gil you can get crash.
Sorry — there’s a small misunderstanding around “crash.” By “crash,” I meant a CPython-internal bug that takes down the whole interpreter, so I was saying you basically don’t get that kind of crash because of the GIL. In that thread, “crash” means a Python exception raised, and that does happen.
and i asked if with or without gil you can get crash.
Yes — it can “crash” both with and without the GIL; I’ve verified that.
The cause is this pattern:
if i in state:
time.sleep(0.0)
del state[i]
It looks like you check that i is in state and then operate on it. But in reality, worker2 can clear state in between, so there’s a data race / thread-safety issue — and that’s what triggers the crash.
i want to see if i can get possible all kinds of issues
Fundamentally, GIL-related problems mostly are: two threads operating on the same object without proper synchronization (locks, atomic operations, etc.).
Yeah, I think me saying “crash” in my example was confusing. Probably if I say “exception” would be better. In general, data races in pure Python code should not crash Python (seg fault, etc). Instead, you get unexpected results or you get a Python exception. If Python crashes itself, not raising an exception, we would generally consider that a Python bug that needs to be fixed.
If you are writing native code, e.g. using the C API to write a Python extension, then a race condition could certainly cause a “hard” crash (no exception, program exits with core dump or whatever). Hope that helps.