[Python-ideas] Concurrent safety?

[Jim Jewett]

On Sun, Oct 30, 2011 at 11:11 PM, Mike Meyer <mwm at mired.org> wrote:

> Python, as a general rule, tries to be "safe" about things. If
> something isn't obviously correct, it tends to throw runtime errors to
> let you know that you need to be explicit about what you want.  ...

> The one glaring exception is in concurrent programs. ...

> Object semantics don't need to change very much. The existing
> immutable types will work well in this environment exactly as is.

I think a state bit in the object header would be more than justified,
if we could define immutability.  Are strings immutable?  Do they
become immutable after the hash is cached and the string is marked
Ready?  Can a subtype of strings with mutable attributes (that are not
involved in comparison?) still be considered immutable?

> The protection mechanism is the change to the language. I propose a
> single new keyword, "locking", that acts similar to the "try"
> keyword. The syntax is:

> 'locking' value [',' value]*':' suite

> ... The list of values are the objects that can be mutated in this
> lock.

You could already simulate this with a context manager ... it won't
give you all the benefits (though with a lint-style tool, it might),
but it will showcase the costs.  (In terms of code beauty, not
performance.)

Personally, I think those costs would be too high, given the current
memory model, but I suppose that is at least partly an empirical
question.

If there isn't a way to generate this list automatically, it is the
equivalent of manual memory management.

-jJ