[IronPython] IronPython cs Cpython wrt GIL

[Phil Frost]

On Wed, Oct 13, 2004 at 03:30:53PM -0700, Curt Hagenlocher wrote:
> Curt Hagenlocher <curt at hagenlocher.org> wrote:
> 
> > What's the granularity of Python's lock?  Per-statement?
> 
> And before anyone answers, here's how I remember the situation,
> pre-2.0.
> 
> The interpreter lock was held per-Python statement.  BUT, many
> of the internal library calls were hardcoded to release the
> lock before executing a C library call and then reacquire the
> lock after the call was done.
> 
> Am I close?

The lock is actually held when CPython is running its eval loop, and is
released every 100 python instructions by default. When C extensions are
making calls to blocking functions that don't manipulate python objects,
they release the lock, for the call.

Thus, the overhead of the lock is significantly lowered since it is not
manipulated for every statement. However, it's such a problem with SMP
boxen that I'd rather have a finer granularity lock. SMP is becoming
more common each day, so I think this will only become a bigger problem.

I think a good solution is to provide a builtin mixin class that adds a
lock around all operations on a class. For the sake of compatability
including this could be the default.