Leif Walsh wrote:
I see that now, but wasn't the original post about removing the GIL? That seems to imply that the users would be different threads in a program, with high speed and possibly high collision rate.
When I said 'impractical', I was thinking about this sort of situation. 'Optimistic Concurrency' is optimistic about not colliding ;-). Else the recovery overhead makes it worse than locking.
If we are talking about users communicating over http, this seems like something you'd write a program in python to do (like wikipedia says Rails does), and it doesn't seem to merit discussion in the development of python itself.
Servers have several threads, each communicating with and representing to the rest of the system one user. When those several threads all edit shared data, should they have to acquire GIL, local locks, or none at all? The point of the article is that 'no lock' is desirable when many locks would be left to expire unused and often also possible. tjr