[Python-ideas] Concurrent safety?

Mike Meyer mwm at mired.org
Mon Oct 31 20:31:50 CET 2011


On Mon, Oct 31, 2011 at 12:14 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 31 Oct 2011 12:03:14 -0700
> Mike Meyer <mwm at mired.org> wrote:
>>
>> Doesn't that cover all kinds of good programming? But advanced
>> language features are there because they are supposed to help with
>> either abstraction or separation of concerns. Look at the list I
>> presented again:
>>
>> - High level languages.
>> - Byte-compiled languages.
>> - Structured programming.
>> - Automatic memory management.
>> - Dynamic typing.
>> - Object Oriented languages.
>>
>> All help with either abstraction or separation of concerns in some way
>> (ok, byte-compilation the concerns are external, in that it's code
>> portability). So do the features I'd like tosee.
>
> I don't think the latter is true. Manually listing objects that are
> allowed to be mutated seems actually quite low-level to me.

Did you not read the next paragraph, the one where I explained how it
helped separate issues?

But you're right. Manually listing them isn't all that desirable, it's
just better than what we have now. I initially saw a locking keyword
with no list as implying that  all such things should be locked
automatically. I can't see how to do that with the locking
implementation, so I dropped it. However, it can be done with an STM
implementation.

Hmm. That could be the distinguishing feature to deal with IO: If you
don't have the list, you get an STM, and it does the copy/fingerprint
dance when you mutate something. If you list a value, you get real
locks so it won't retry and you can safely do IO.

     <mike



More information about the Python-ideas mailing list