I have not experienced this myself, but see
http://stackoverflow.com/questions/2246384/multiprocessing-pool-hangs-when-there-is-a-exception-in-any-of-the-thread

This appears to be another case of http://bugs.python.org/issue1692335

I also recently reported a similar problem at http://bugs.python.org/issue13751

Looking at the code for `NoOptionError` (see below) in 2.6 at least it would indeed be subject to the same problem. Perhaps some attention could be paid to 
resolving 1692335, which would presumably make this vexing problem go away?

class NoOptionError(Error):
    """A requested option was not found."""

    def __init__(self, option, section):
        Error.__init__(self, "No option %r in section: %r" %
                       (option, section))
        self.option = option
        self.section = section

New changeset e63e2471f46f by Łukasz Langa in branch 'default':
#13760: picklability tests for configparser exceptions
http://hg.python.org/cpython/rev/e63e2471f46f

New changeset 76077971ee1f by Łukasz Langa in branch '3.2':
#13760: picklability tests for configparser exceptions
http://hg.python.org/cpython/rev/76077971ee1f

New changeset 5ecf650ede7c by Łukasz Langa in branch '2.7':
Fixes #13760: picklability of ConfigParser exceptions
http://hg.python.org/cpython/rev/5ecf650ede7c

3.2 and 3.3 already worked as expected. For 2.7 I did the __reduce__ workaround that's also used by SQLAlchemy.

Thanks for the quick attention to this, Lukasz. I'm just curious. Why do 3.2 and 3.3 already work? My understanding was that the basic exception issue in http://bugs.python.org/issue1692335 was still open.

The reason why 3.2 and 3.3 work is that some time ago I fixed #4686 by explicitly settings .args in configparser exceptions. Unfortunately that patch was not backported at the time. I did that just now.

You're right, that is specific to configparser and doesn't affect #1692335 which is still unsolved.

I see. Thanks for the pointer to the earlier (2008) bug report. I notice you fixed the bug differently for 2.7 (define __reduce__) and 3.2 (set args). Is there some reason for that?

Currently both branches use the same solution to the problem (e.g. setting `args` in `__init__()`). I simply forgot about the old ticket when I prepared a fix for this one.