global interpreter lock not working as it should

[anton wilson]

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. 


>
> Regards,
> Martin