[Python-ideas] Concurrent safety?

[Mike Meyer]

On Mon, Oct 31, 2011 at 7:33 AM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> 2011/10/31 Mike Meyer <mwm at mired.org>
>> Any attempt to mutate an object that isn't currently locked will raise
>> an exception. Possibly ValueError, possibly a new exception class just
>> for this purpose. This includes rebinding attributes of objects that
>> aren't locked.
> PyPy offers a nice platform to play with this kind of concepts.
> For example, even if it's not the best implementation, it's easy to add a
> __setattr__ to the base W_Object class, which will check whether the object
> is allowed to mutate.
> But you certainly will open a can of worms here: even immutable objects are
> modified (e.g str.__hash__ is cached) and many functions that you call will
> need to add their own locks, is it possible to avoid deadlocks in this case?

Just what I need - another project. I'll go take a look at PyPy.

In theory, things that don't change the externally visible behavior of
an object don't need to be checked. The goal isn't to make the
language perfectly safe, it's to make you be explicit about when you
want to do something that might not be safe in a concurrent
environment.

This provides a perfect example of where an immutable subclass would
be useful. It would add an __setattr__ that throws an exception. Then
the string class (which would inheret from the immutable subclass)
could cache it's hash by doing something like
W_Object.__setattr__(self, "_cashed_hash", hash(self)) (possibly
locked).

   <mike