[issue35778] RF: ``pathlib.Path.checksum()`` member

New submission from Oscar Esteban : Gauging the interest in a checksum calculation function built-in Path objects: ``` >>> Path('somefile.img').checksum() '4976c36bacf922cbc5c811c9c288e61d' >>> Path('somefile.img').checksum(hash='md5') '4976c36bacf922cbc5c811c9c

[issue35238] Alleviate memory reservation of fork_exec in subprocess.Popen via forkserver

Oscar Esteban added the comment: Hi Victor, That would be great. However, we played a bit with an alternative implementation of posix_spawn (one I got from one related bpo), and it didn't seem to make any difference in terms of memory allocation. Then, we found out that posix_spawn uses

[issue35238] Alleviate memory reservation of fork_exec in subprocess.Popen via forkserver

Oscar Esteban added the comment: Thanks for your response. The idea would be to enable ``subprocess.Popen`` to use an existing fork server in its fork_exec. The rationale: I can start a pool of n workers very early in the execution flow. They will have ~350MB memory fingerprint

[issue35238] Alleviate memory reservation of fork_exec in subprocess.Popen via forkserver

New submission from Oscar Esteban : ## Context We are developers of nipype (https://github.com/nipype) which is a workflow engine for neuroimaging software. We are experiencing problems that gave rise to the addition of ``os.posix_spawn`` to Python 3.8, and particularly, this - https

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Oscar Esteban added the comment: I tried to reuse as much as I could from the patch, but it didn't solve the issue at first. I have changed the responsibility of identifying and prescribing a solution when a worker got killed. In the proposed patch, the thread handling results (i.e. tasks

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Change by Oscar Esteban : -- pull_requests: +9713 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue22393> ___ ___ Python-

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Oscar Esteban added the comment: Hi Antoine, I may take a stab at it. Before I start, should I branch from master or from 3.7.1 (as 3.7 is still accepting bugfixes). Best, Oscar -- ___ Python tracker <https://bugs.python.org/issue22

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Oscar Esteban <oeste...@stanford.edu> added the comment: We use multiprocessing to parallelize many tasks that run either python code or call subprocess.run that are memory hungry. At times the OOM Killer kicks in. When one of the workers is killed, the queue never returns an