sturlamolden wrote: > On Jun 4, 10:11 pm, Josiah Carlson <[EMAIL PROTECTED]> > wrote: > >> However, locking isn't just for refcounts, it's to make sure that thread >> A isn't mangling your object while thread B is traversing it. > > >> With >> object locking (course via the GIL, or fine via object-specific locks), >> you get the same guarantees, with the problem being that fine-grained >> locking is about a bazillion times more difficult to verify the lack of >> deadlocks than a GIL-based approach. > > I think this is just as much a question of what the runtime should > guarantee. One don't need a guarantee that two threads are not > mangling the same object simultaneously. Instead, the runtime could > leave it to the programmer to use explicit locks on the object or > synchronized blocks to guarantee this for himself.
Why? Right now we have a language where the only thing that doing silly things with threads can get you now is perhaps a deadlock, perhaps incorrect execution, or maybe some data corruption if you are working with files. If we forced all thread users to synchronize everything themselves, we get an uglier language, and incorrectly written code could potentially cause crashes (though all of the earlier drawbacks still apply). In the "safety vs. speed" or "easy vs. fast" arenas, Python has already chosen safe and easy rather than fast. I doubt it is going to change any time soon. >> It was done a while ago. The results? On a single-processor machine, >> Python code ran like 1/4-1/3 the speed of the original runtime. When >> using 4+ processors, there were some gains in threaded code, but not >> substantial at that point. > > I am not surprised. Reference counts are quite efficient, contrary to > common belief. The problem with reference counts is cyclic references > involving objects that define a __del__ method. As these objects are > not eligible for cyclic garbage collection, this can produce resource > leaks. There was a discussion about removing __del__ within the last couple weeks. I didn't pay much attention to it (having learned never to use __del__), but I believe it involved some sort of weakref-based cleanup. - Josiah -- http://mail.python.org/mailman/listinfo/python-list
