title: Python 3.8 concurrent.futures "OSError: handle is closed"
body: <p>I have Python 3.8 and cannot upgrade (I have dependencies that only work with Python 3.8), so <a href="https://stackoverflow.com/questions/63926326/python-concurrent-futures-error-in-atexit-run-exitfuncs-oserror-handle-is-clo">this SO post</a> does not answer my question. How do I prevent the <code>OSError: handle is closed</code> error? This happens when returning a result to the main thread. Here is a very trivial example:</p>
  <pre class="lang-py prettyprint-override"><code>from concurrent.futures import ProcessPoolExecutor
  
  
  def my_func(num):
      return num + 1
  
  
  def worker(data):
      with ProcessPoolExecutor(5) as executor:
          result = executor.map(my_func, data)
      return result
  
  
  if __name__ == &quot;__main__&quot;:
      arr = [1, 2, 3, 4, 5]
      print(arr)
      arr = worker(arr)
      print(tuple(arr))
  </code></pre>
  <p>This gives</p>
  <pre><code>[1, 2, 3, 4, 5]
  (2, 3, 4, 5, 6)
  Error in atexit._run_exitfuncs:
  Traceback (most recent call last):
    File &quot;C:\Users\hendra11\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\process.py&quot;, line 102, in _python_exit
      thread_wakeup.wakeup()
    File &quot;C:\Users\hendra11\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\process.py&quot;, line 90, in wakeup
      self._writer.send_bytes(b&quot;&quot;)
    File &quot;C:\Users\hendra11\AppData\Local\Programs\Python\Python38\lib\multiprocessing\connection.py&quot;, line 183, in send_bytes
      self._check_closed()
    File &quot;C:\Users\hendra11\AppData\Local\Programs\Python\Python38\lib\multiprocessing\connection.py&quot;, line 136, in _check_closed
      raise OSError(&quot;handle is closed&quot;)
  OSError: handle is closed
  </code></pre>
  <p>Does anyone know what's causing this bug and how I can manually fix it?</p>
  <p>If it matters, I'm on Windows 10 running Visual Studio Code.</p>
  <p><strong>UPDATE:</strong> This error goes away when I use <code>ThreadPoolExecutor</code> AND it is much faster, but I don't know why.</p>