global interpreter lock not working as it should

[Jeff Epler]

On Wed, Jul 31, 2002 at 10:00:41AM -0400, anton wilson wrote:
> On Tuesday 30 July 2002 09:20 pm, jepler at unpythonic.net wrote:
> > > On Tuesday 30 July 2002 07:18 pm, brueckd at tbye.com wrote:
> > > > Quick tangential question: if there's no blocking of any kind, why are
> > > > you using threads, anyway? Off the cuff thinking says this seems like a
> > > > misuse of them.
> >
> > On Tue, Jul 30, 2002 at 06:48:40PM -0400, anton wilson wrote:
> > > For a real-time system. ;) It will work. It would just be nice if they
> > > switched exactly every 10 byte codes becuase that means they only use
> > > about 10 to 20 milliseconds each.
> >
> > Realtime?  Really?  So can you tell me the upper-bound on the runtime
> > of
> >
> >     >>> x = 3
> >
> > on the hardware you're targeting?
> >
> > Jeff
> 
> 
> Good question. You have any reasons why we should not use python?

It's a trick question.
    >>> x = 3
will do a decref on the old value of x, if it had one.  This could
invoke the __del__ of an arbitrary object, which could call any
C function.  Or, deallocating x could make the reference count of
arbitrarily many objects fall to 0, for instance if the old value of x was
    >>> x = [uniqueobject() for x in range(1000 * 1000)]
then ultimately around 1 million objects would be deallocated as a
result of a single statement. (these deallocations are done with the GIL
held, yet the bytecode loop will not be entered unless uniqueobject has
a __del__ method written in Python)  I won't even mention garbage
collection or other worse issues.

A realtime system places an upper bound on all operations, but the very
nature of Python makes this impractical if not impossible.

An interaction between Python's handling of the GIL and the platform's
pthread library is going to be the least of your problems if you
actually intend to deliver a system which gives realtime guarantees on
Python programs.

Jeff