A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064282.html below:

[Python-Dev] Proposed addition to threading module

[Python-Dev] Proposed addition to threading module - released [Python-Dev] Proposed addition to threading module - releasedGuido van Rossum guido at python.org
Mon Apr 24 20:34:00 CEST 2006
On 4/23/06, "Martin v. Löwis" <martin at v.loewis.de> 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.

Actually, what Nick describes is *exactly* how one should write code
using a condition variable:

  LOCK
  while nothing to do:
      UNLOCK
      wait for the condition variable (or sleep, or whatever)
      LOCK
  # here we have something to do with the lock held
  remove the to-do item
  UNLOCK

except that the outer LOCK/UNLOCK pair should be using a try/except
and the inner UNLOCK/LOCK pair should too. I don't see how you can do
this easily by rewriting the code; the rewrite would be considerably
ugly (or requires a GOTO :-).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4