On Tue, Oct 14, 2008 at 1:38 PM, Terry Reedy <tjreedy@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