[Python-ideas] easy thread-safety [was: fork]

[Andrew Barnert]

On Aug 19, 2015, at 09:57, Ron Adam <ron3200 at gmail.com> wrote:
> 
> On 08/18/2015 01:27 PM, Chris Angelico wrote:
>>>> There's no way to make module globals thread-local without making the
>>>> >>module object itself thread-local, and if you do that, you probably
>>>> >>need to make every object it references thread-local too, etc, etc,
>>>> >>etc.
>>> >
>>> >Something wrong with that? Shouldn't matter as long as there is only a
>>> >single thread.
> 
>> As long as there's only a single thread, there's no difference between
>> process-wide and thread-local. Once you start a second thread,
>> something needs to know what objects belong where. That's all.
> 
> Just a thought...
> 
> What if a new name type, co_mutables, is added to functions objects, and a new keyword to go with it, "mutable" to be used like "globals" and "nonlocals".  And then raise an error on an attempt to bind a mutable object to a name not in co_mutables.
> 
> Also, don't include co_mutables in functions scopes.  That would require mutable objects to be passed as function arguments to be seen.
> 
> Then only mutable objects/names explicitly passed to a new thread need to be tracked.
> 
> It might be possible to turn that on with a compiler directive at the top of a module so normal python code would work normally, and thread safe python code would be limited.
> 
> Would something in this direction simplify the problem?

Well, the problem can be solved with a strong enough static typing system, as multiple ML-derived languages that add mutability and/or unsafety prove. But what you're suggesting doesn't nearly strong enough, or static enough, to accomplish that.

First, in this code, is i mutable or not:

    def spam(a):
        for i in a:
            eggs(i)

And if eggs is imported from a module not marked "thread-safe", does is the call illegal, or assumed to do something that mutates i, or assumed to be safe?

Also, whether eggs is from a "thread-safe" module or a normal one, how does the compiler know whether it's passing i to a new thread?

And what happens if eggs stores i in a list or other mutable object and some other code mutates it later?

Finally, if you only track mutability at the top level, how can you tell the compiler that a (mutable) queue of ints is thread-safe, but a queue of lists is not? And how can the compiler know which one it's looking at without doing a complete whole-program type inference?