Message351705
| Author |
davin |
| Recipients |
davin, pablogsal, pitrou, steve.dower, vstinner |
| Date |
2019年09月10日.15:38:20 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1568129900.43.0.99791768828.issue38084@roundup.psfhosted.org> |
| In-reply-to |
| Content |
Sharing for the sake of documenting a few things going on in this particular example:
* When a PoolWorker process exits in this way (os._exit(anything)), the PoolWorker never gets the chance to send a signal of failure (normally sent via the outqueue) to the MainProcess.
* In the current logic of the MainProcess, Pool._maintain_pool() detects the termination of that PoolWorker process and starts a new PoolWorker process to replace it, maintaining the desired size of Pool.
* The infinite hang observed in this example comes from the original p.map() call performing an unlimited-timeout wait for a result to appear on the outqueue, hence an infinite wait. This wait is performed in MapResult.get() which does expose a timeout parameter though it is not possible to control through Pool.map(). It is not at all a correct, general solution, but exposing the control on this timeout and setting it to 1.0 seconds permits Steve's repro code snippet to run to completion (no infinite hang, raises a multiprocessing.context.TimeoutError). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2019年09月10日 15:38:20 | davin | set | recipients:
+ davin, pitrou, vstinner, steve.dower, pablogsal |
| 2019年09月10日 15:38:20 | davin | set | messageid: <1568129900.43.0.99791768828.issue38084@roundup.psfhosted.org> |
| 2019年09月10日 15:38:20 | davin | link | issue38084 messages |
| 2019年09月10日 15:38:20 | davin | create |
|