[Python-ideas] Optimistic Concurrency

[Leif Walsh]

On Tue, Oct 14, 2008 at 1:38 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> It does not strike me as practical for Python.

Probably true, but let's see....

> 1. It starts with copying data.  Clients accessing a database server already
> do this.  Threads accessing *shared* data normally do not.

Agreed, but if I want them to, they should (and I should be able to
tell that to python concisely, and have python understand what that
means for concurrency).

> 2. Any edit (change) may be discarded in part or in whole.  Human operators,
> informed of the rejection, must (and 'somehow' do) decide what to do.
>  Wrapping every assignment to shared data with a pre-programmed
> RejectionException handler would usually be a huge burden on the programmer.

It would be a huge burden, but perhaps it could be an option for the
especially ambitious programmer.  Might there be a way to tell the
interpreter, "hey buddy, I've written all the RejectionException
handlers, why don't you just let go of the GIL for now and use this
other thing instead"?

I could see this becoming very difficult if there were some kind of
on/off switch you could trigger from inside python (what happens when
_that_ has a race condition? O_o), but if you could have it on a
per-program-run basis, it might be useful.  Certainly, you could then
go and exec() an program that does this, and break it that way, but
hopefully, if you understand enough to use the switch in the first
place, you'd understand how bad of an idea this would be.

For a long time, I've wanted to see a strong guarantee of
concurrency-invariance in python, especially when dealing with swigged
modules, which have a tendency to blunder right on past the GIL.  I
think having a secondary mode that allows this might be the slow,
gentle path we need.  After all, I nearly dropped python altogether
when I discovered Erlang (before I discovered its syntax, of course),
for just this reason.

-- 
Cheers,
Leif