Derek Wilson <jderekwil...@gmail.com> added the comment: While having multiprocessing use a timeout would be great, I didn't really have the time to fiddle with the c code.
Instead of using the socket timeout, I'm modifying all the sockets created by the socket module to have no timeout (and thus to be blocking) which makes the multiprocessing module 'immune' to the socket module's default timeout. For testing, I just run the test suite twice, once with the initial default socket timeout and once with a 60 second timeout. Nothing there failed with this issue. It is worth noting, however, that when using a default socket timeout, for some reason processes that have have put data into a queue no longer block at exit waiting for the data to be consumed. I'm not sure if there is some additional cleanup code that uses sockets and might need to block? Or maybe whatever the issue was with blocking sockets is not an issue with non-blocking sockets? ---------- keywords: +patch Added file: http://bugs.python.org/file22376/mpsock.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6056> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
