global interpreter lock not working as it should
anton.wilson at camotion.com
Fri Aug 2 00:20:25 CEST 2002
On Thursday 01 August 2002 02:57 am, Martin v. Loewis wrote:
> anton wilson <anton.wilson at camotion.com> writes:
> > One final clarification on this subject is that with the current
> > version of python on my system, the GIL never blocks, and that is
> > why I was complaining. The only reason other threads get scheduled
> > is because threads run out of time.
> Unfortunately, this does not clarify: If another Python thread gets
> activated and performs byte code instructions, that *necessarily*
> means that it holds the GIL, and that the first thread now blocks in
> the GIL.
> So if you see other threads running eventually, it must mean that the
> GIL blocks.
Ok, I believe that you are right. Taking hints from Tim Peters I checked to
see when Linux delivers signals. It delivers immediately but it can only
handle signals if the process that recieved the signal is currently running.
It handles signals both on an interrupt return and from inside the system
call that waits on signals, such as the one a process blocked on the GIL
mutex would be inside of (it's implemented by a while loop with a reschedule
call in the loop). The only problem is that the process has to be scheduled
on the CPU to handle a signal. Therefore, any thread blocked on the GIL mutex
will only successfully get the signal and grab the mutex when it is
rescheduled by the OS.
More information about the Python-list