Why GIL? (was Re: what's the point of rpython?)

[Bryan Olson]

Carl Banks wrote:
> Bryan Olson wrote:
>> Paul Rubin wrote:
>>> Bryan Olson writes:
>>>>> BTW, class instances are usually immutable and thus don't require a
>>>>> mutex in the system I described.

>>>> Then you are describing a language radically different from Python.

>>> That one threw me for a minute too, but I think the idea is that the
>>> class instance itself is immutable, while its slots (specifically the
>>> attribute dictionary) point to mutable objects.

>> The meaning of 'immutable' is well-established in the Python literature.
>> Python's immutable types include tuple, frozenset, and various kinds of
>> numbers and strings. Class instances, not so much.
> 
> Of course class instances aren't immutable types: they're not even
> types. 

Class instances my or may not be types, but that has nothing to do with 
any point at issue here. I'm saying that class instances are usually, 
mutable, contrary to your claim, "class instances are usually immutable".

> Let me suggest that there is a distinction between an
> immutable type and an immutable object.

Let me further suggest that Python's documentation is entirely clear: 
instances of immutable types are immutable objects. Instances of mutable 
types are generally mutable objects. For example, tuple is an immutable 
type, and thus tuples are immutable; list is a mutable type, and thus 
lists are mutable.

> Immutable types are what you are talking about: it means that the type
> provides usable mutator methods.  (Whether they mutate the object
> itself or some associated object doesn't matter.)  Immutable objects
> are a different thing: it means the object cannot change in memory.
> 
> Classes in Python are mutable types, usually.  Class instances are
> (except for the refcount) immutable objects, usually.

There's where we disagree. I assert that class instances are usually 
mutable objects.

> We usually talk about mutability of types, but mutability of objects
> is appropriate for discussion as well.  So I can't really agree with
> your assessment that I wrong to call class instances immutable objects
> aside from refcounts.

That confusion disappears once one grasps that instances of immutable 
types are immutable objects.

> BTW, here's a minor brain bender: immutable types are mutable objects.

Some brains are too easily bent. Python is one of the many 
object-oriented languages that reifies types as run-time objects. I see 
no point in going through Python's immutable types to examine if there 
is any way to mutate the corresponding type objects.


>> What's more, this matters when considering a GIL-less implementation.
>> Typical method calls can traverse lots of mutable stuff just to find the
>> function to invoke.
> 
> Now that doesn't make sense at all.  What is all this mutable stuff
> you have to go through, and what does it have to do with the GIL-less
> implementation?  Can you explain further?  Or are you just saying
> it'll be slow.

I elaborated at some length in another strand of this thread.


-- 
--Bryan