[issue14148] Option to kill "stuck" workers in a multiprocessing pool

Changes by Brian Quinlan : -- nosy: +bquinlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue14148] Option to kill "stuck" workers in a multiprocessing pool

Paul Moore added the comment: As an alternative, maybe leave the "stuck" worker, but allow the pool to recognise when a worker has not processed new messages for a long period and spawn an extra worker to replace it. That would avoid the starvation issue, and the stuck workers would die when the

[issue14148] Option to kill "stuck" workers in a multiprocessing pool

Antoine Pitrou added the comment: The problem is that queues and other synchronization objects can end up in an inconsistent state when a worker crashes, hangs or gets killed. That's why, in concurrent.futures, a crashed worker makes the ProcessPoolExecutor become "broken". A similar thing sho

[issue14148] Option to kill "stuck" workers in a multiprocessing pool

New submission from Paul Moore : I have an application which fires off a number of database connections via a multiprocessing pool. Unfortunately, the database software occasionally gets "stuck" and a connection request hangs indefinitely. This locks up the whole process doing the connection,