title: Arbitrary sleeping in threading's wait with timeout
body: <p>Before I start describing my question, it might worth mentioning that I'm using Python 2.7. I haven't checked, but this might be irrelevant for Python 3.x.</p>
  
  <p>While working with Python's <a href="http://docs.python.org/2/library/queue.html#module-Queue">Queues</a>, I've discovered something strange. Usually, when <em>getting</em> an object from the Queue, I allow long but finite timeout (such as a few seconds), to allow debugging and error reporting in case no object was found, when one was expected. What I've found out is that sometimes there's a strange gap between the time when an object was inserted into a previously empty Queue, and the time the <code>get</code> method of the very same Queue has returned that object, even though the method was called before the <code>put</code> was called for that object.</p>
  
  <p>Digging a little bit I've discovered that the gap was filled by sleeping. In the <code>Queue</code> module, if the <code>timeout</code> argument that is being passed to the <code>get</code> method is not <code>None</code>, and is positive, the <code>non_empty</code> <a href="http://docs.python.org/2/library/threading.html#condition-objects"><code>Condition</code></a>'s <code>wait</code> method is called with a positive argument (that is not 100% precise; in fact, the <code>Queue</code>'s "<code>_qsize</code>" method, which returns the length of the underlying <code>deque</code> is first verified to return 0, but as long as the queue was empty in the first place, the next thing is the condition's wait).</p>
  
  <p>The <code>Conditions</code>'s <code>wait</code> method acts differently if it gets a timeout or not. If it does not get any timeout, it simply calls <code>waiter.acquire</code>. This is defined in <code>C</code> and is beyond what I understand, but it seems like it works properly. However, if timeout <strong>is</strong> given, a bizarre sequence of sleeps occur instead, when the sleep times start at some arbitrary size (1 milisecond), and gets longer over time. Here's the exact code which runs:</p>
  
  <pre><code># Balancing act:  We can't afford a pure busy loop, so we
  # have to sleep; but if we sleep the whole timeout time,
  # we'll be unresponsive.  The scheme here sleeps very
  # little at first, longer as time goes on, but never longer
  # than 20 times per second (or the timeout time remaining).
  endtime = _time() + timeout
  delay = 0.0005 # 500 us -&gt; initial delay of 1 ms
  while True:
      gotit = waiter.acquire(0)
      if gotit:
          break
      remaining = endtime - _time()
      if remaining &lt;= 0:
          break
      delay = min(delay * 2, remaining, .05)
      _sleep(delay)
  </code></pre>
  
  <p>This is clearly the reason for the gap I've found between the time the new object was put into the previously-empty Queue, and the time that the already-called get method has returned that object. As the delay time grows exponentially until blocked by a huge (from my perspective) size of 0.05 seconds, it creates surprising and unwanted significant sleeps in my application's life.</p>
  
  <p>Can you explain what's the purpose of this? Are Python developers assume no Python user will care about such time lengths? Is there a quick workaround or a proper fix? Do you recommend me to overload the threading module?</p>