[Python-Dev] Proposed addition to threading module - released

[Nick Coghlan]

Martin v. Löwis wrote:
> Nick Coghlan wrote:
>> Do we want to add a "released" context manager to the threading module for 
>> 2.5? 
> 
> I don't think that should be added. I would consider it a dangerous
> programming style: if the lock merely doesn't "need" to be held (i.e.
> if it isn't necessary, but won't hurt), one should just keep holding
> the lock. If it is essential to release the lock, because the code
> would otherwise deadlock, the code should be dramatically revised
> to avoid that situation, e.g. by redefining the granularity of the
> lock, and moving the with statements accordingly.

That isn't always possible or practical, though - Python's own GIL is a case 
where releasing it around long-running operations (such as blocking I/O 
operations) that don't need it provides significant benefits for threaded 
code, but redesigning the lock to use finer granularity causes its own problems.

I'm not going to argue particularly strongly (or at all, really) for this one, 
since I think threading.Thread + Queue.Queue is a much better way to write 
threaded Python programs. The blocking IO 'asynchronize' use case in PEP 319 
was just something I happened to notice in looking back at the various PEP's 
that were rejected in favour of PEP 343.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org