another thread on Python threading

[Josiah Carlson]

sturlamolden wrote:
> On Jun 4, 10:11 pm, Josiah Carlson <josiah.carl... at sbcglobal.net>
> 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