multithreading

[Mark Hammond]

Aahz wrote:
> In article <mailman.1022277883.28027.python-list at python.org>,
> =?iso-8859-1?q?Fran=E7ois?= Pinard <pinard at iro.umontreal.ca> wrote:
> 
>>[Aahz]
>>
>>>My response is that instead of trying to take advantage of the few
>>>atomic Python constructs, instead code defensively and always use
>>>thread-safe mechanisms for passing information.  Because Python has a
>>>powerful and simple Queue, this is straightforward to accomplish.
>>
>>But abusing Queues for very simple things, a bit everywhere, might yield
>>code bloat, and impinge readability.  This is a bit like if someone was
>>inviting everyone to abuse fixed point integer arithmetic all over as a
>>way to program defensively against floating point arithmetic.
> 
> 
> You're both misreading me and overstating your point, IMO.  I completely
> agree that RLock() is a valuable and necessary tool for managing critical
> sections of code.  However, I stand by my claim that Queue() should be
> the primary mechanism for passing data around.  Getting the semantics of
> Event() and Semaphore() correct (not even talking about Condition() --
> <shudder>) can be extremely difficult for all but the simplest cases,
> leading to application deadlock.
> 
> Queue is both powerful and simple, and I therefore invoke Python's
> "There's Only One Way" principle.

You can invoke whatever you like, but it doesn't change anything for 
anyone else ;)

I believe advocating the Queue module as the "one way" is naive.  The 
Queue module is very useful, and indeed has solved many threading 
problems in an elegant way for me - however, in my experience, it has 
been used in less than 50% of the times I have needed mutli-threaded 
synchronization.

If-your-only-tool-is-a-hammer-everything-starts-looking-like-a-thumb ly

Mark.