Python threading (was: Re: global interpreter lock not working as it should)

[anton wilson]

On Tuesday 06 August 2002 03:38 pm, Martin v. Loewis wrote:
> anton wilson <anton.wilson at camotion.com> writes:
> > > > The timer tick does happen 100x per second and since python gives up
> > > > the lock every 10 us or so, it's really not a huge coincidence for
> > > > an overlap. I just don't really like the reliance on this
> > > > coincidence.
> > >
> > > Accept it. It is meant to work this way.
> >
> > I understand that, but still . . . you have to agree that the ratio here
> > is pretty horrible for certain systems even if it was supposed to be
> > cross-platform. It works as it should, but for this particular OS, it
> > could be helped along. There's nothing wrong with being more efficient if
> > you can be and it won't hurt any design goals.
>
> I'm all in favour of efficiency. However, adding more thread switches
> is likely to hurt efficiency, instead of increasing it.

This is true; however, we're still making tons of system calls to lock, 
unlock and signal every ten byte-codes . . . system calls aren't very fast 
either because you have to drop into kernel mode (also a switch). So my 
stance is, it would be nice if all that work weren't completely in vain, and 
actually served a purpose at least half of the time. So for systems who 
really care about decreasing switching in the name of time, 
sys.setcheckinterval(x) exists.


Anton