Setting limits in sub-process
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- backend, distributed-systems
Direzione di ricerca
Start by reproducing the supplied multiprocessing fork example on AlmaLinux 8.9 with Python 3.12.3 and threadpoolctl 3.4.0, then trace the library scan through libc.dl_iterate_phdr and match_library. Compare the behavior with CentOS 7; the issue reports the scan hanging in the newer environment. Done means identifying and fixing the hang, with a regression test for the reported subprocess scenario.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Calling threadpool_limits in a sub-process fails (hangs) on some of my servers but fails in ones with a specific OS version:
$ hostnamectl
Static hostname: n86.my.domain
Icon name: computer-server
Chassis: server
Machine ID: 196b497eccff4526a8e34834c95e3de5
Boot ID: b8318d26cd394a85b706beb2d7324f73
Operating System: AlmaLinux 8.9 (Midnight Oncilla)
CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
Kernel: Linux 4.18.0-513.18.2.el8_9.x86_64
Architecture: x86-64
The code is:
import os
import sys
from threadpoolctl import threadpool_limits
from multiprocessing import get_context
def eprintln(text):
print(text, file=sys.stderr, flush=True)
DID_THREADCTL_FOR_PID = None
def invocation(index: int) -> int:
global DID_THREADCTL_FOR_PID
if os.getpid() != DID_THREADCTL_FOR_PID:
DID_THREADCTL_FOR_PID = os.getpid()
eprintln(f"PID: {os.getpid()} invocation index: {index} Do threadpool_limits...")
threadpool_limits(limits=1)
eprintln(f"PID: {os.getpid()} invocation index: {index} Did threadpool_limits.")
else:
eprintln(f"PID: {os.getpid()} invocation index: {index} Old threadpool_limits.")
return index
invocations = 4
processes = 2
threadpool_limits(limits=processes)
results = [None] * invocations
eprintln(f"PID: {os.getpid()} Do imap...")
with get_context("fork").Pool(2) as pool:
for index in pool.imap_unordered(invocation, range(invocations)):
results[index] = index
eprintln(f"PID: {os.getpid()} - Did imap index: {index}")
eprintln(f"PID: {os.getpid()} Did imap results: {results}")
assert results == list(range(len(results)))
When I run it on the above OS, in Python 3.12.3, threadpoolctl version 3.4.0, I get:
$ python3 bug.py
PID: 1576849 Do imap...
PID: 1576852 invocation index: 0 Do threadpool_limits...
PID: 1576853 invocation index: 1 Do threadpool_limits...
PID: 1576853 invocation index: 1 Did threadpool_limits.
PID: 1576853 invocation index: 2 Old threadpool_limits.
PID: 1576853 invocation index: 3 Old threadpool_limits.
PID: 1576849 - Did imap index: 1
PID: 1576849 - Did imap index: 2
PID: 1576849 - Did imap index: 3
And the process hangs. Poking around it seems that libc.dl_iterate_phdr does not return (each match_library_callback call does return). I am using a Python 3.12.3 that was compiled from source on this OS, followed by pip installation of numpy, pandas, scipy etc.
This same thing works fine in older versions of the OS. E.g., in:
$ hostnamectl
Static hostname: n97.my.domain
Icon name: computer-server
Chassis: server
Machine ID: 5e543d50691943628e8e20441f502406
Boot ID: 0d876250c0ec4a149e8bdb12c99c20eb
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.15.2.el7.x86_64
Architecture: x86-64
With Python version 3.12.2, again with threadpoolctl version 3.4.0, I get the expected output:
$ python3 bug.py
PID: 32872 Do imap...
PID: 32874 invocation index: 0 Do threadpool_limits...
PID: 32875 invocation index: 1 Do threadpool_limits...
PID: 32874 invocation index: 0 Did threadpool_limits.
PID: 32875 invocation index: 1 Did threadpool_limits.
PID: 32874 invocation index: 2 Old threadpool_limits.
PID: 32872 - Did imap index: 0
PID: 32875 invocation index: 3 Old threadpool_limits.
PID: 32872 - Did imap index: 1
PID: 32872 - Did imap index: 2
PID: 32872 - Did imap index: 3
PID: 32872 Did imap results: [0, 1, 2, 3]
Any ideas on what I can do to fix this?
- Lingua principale
- Python
- Stelle
- 434
- Fork
- 38
- Merge medio
- 2g 14h
- PR unite (30g)
- 8
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di joblib/threadpoolctl
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
joblib/threadpoolctl#274 ·
I maintainer di solito rispondono entro 1 giorno
-
Make it possible to set active/spin wait behavior of LLVM/Intel OpenMP via `kmp_set_blocktime`Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
joblib/threadpoolctl#271 ·
I maintainer di solito rispondono entro 1 giorno
-
Make it possible to inspect active/spin wait behavior of LLVM/Intel OpenMP via `kmp_get_blocktime`Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
joblib/threadpoolctl#270 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 22/100
joblib/threadpoolctl#261 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Opt-in API that has a cached `ThreadpoolController`Forse già presa @itamarst l’ha presa 29 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
joblib/threadpoolctl#254 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di joblib/threadpoolctl
Issue simili
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendForse già presa @debesh-biswas l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
`rx.Model` event arguments emit `PydanticDeprecatedSince20` once per payload keyForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
reflex-dev/reflex#7634 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 82/100
topoteretes/cognee#6239 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ranaroussi/yfinance#3009 ·
I maintainer di solito rispondono entro 1 giorno
-
Test discovery aborts on GPU builds without cuStateVec: check_cuStateVec expects a failed result but set_config() now raises RuntimeErrorForse già presa @dmeliksetian l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Qiskit/qiskit-aer#2495 ·
I maintainer di solito rispondono entro 1 giorno