title: Does it make sense to multi-thread within multiprocessing?
body: <p>With Python's multiprocessing, would it make sense to have a <code>Pool</code> with a bunch of <code>ThreadPool</code>s within them? Say I have something like:</p>
  <pre><code>def task(path):
    # i/o bound
    image = load(path)
    # cpu bound but only takes up 1/10 of the time of the i/o bound stuff
    image = preprocess(img)
    # i/o bound
    save(image, path)
  </code></pre>
  <p>Then I'd want to process a list of paths <code>path_list</code>. If I use <code>ThreadPool</code> I still end up hitting a ceiling because of the cpu bound bit. If I use a <code>Pool</code> I spend too much dead time waiting for i/o. So wouldn't it be best to split <code>path_list</code> over multiple processes that each in turn use multiple threads?</p>
  <p><strong>Another shorter way of restating my example is</strong> what if I have a method that should be multithreaded because it's i/o bound but I also want to make use of many cpu cores? If I use a <code>Pool</code> I'm using each core up for a single task which is i/o bound. If I use a <code>ThreadPool</code> I only get to use one core.</p>