With ongoing discussion about the desire to remove the GIL from Python, I made this utility so that people can actually profile what proportion of the time the GIL is held in their code, because we shouldn't be arguing about making optimisations when we can't profile.
In my experience, in a lot of code (numerics is my background), the GIL is actually not held most of the time, and so programs can benefit from multithreading despite the GIL, as competition for it is low.
I also think this package is a bit clever - since the GIL is not exposed to Python code, I had to do some trickery to access it and check if is held or not. The code basically reads the data segment of process memory, and acquires and releases the GIL to see what changed, and uses that information to determined where in memory the variables for the GIL are located.
1 comment
[ 2.8 ms ] story [ 14.4 ms ] threadIn my experience, in a lot of code (numerics is my background), the GIL is actually not held most of the time, and so programs can benefit from multithreading despite the GIL, as competition for it is low.
I also think this package is a bit clever - since the GIL is not exposed to Python code, I had to do some trickery to access it and check if is held or not. The code basically reads the data segment of process memory, and acquires and releases the GIL to see what changed, and uses that information to determined where in memory the variables for the GIL are located.