Idea: changing libuv not to install a signal handler
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- linux, python
- Ambito
- backend, operating-systems
Direzione di ricerca
Inizia esaminando la modifica proposta in libuv/libuv#4179 e il modo in cui uvloop utilizza attualmente libuv per la gestione dei processi figli e dei segnali. Confronta questo comportamento con i child watcher di Python, il supporto a pidfd su Linux e i thread di attesa dedicati utilizzati altrove; il lavoro sarà considerato completato quando sarà definito un design di integrazione deciso e sicuro con test appropriati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi,
So I've been having problems with a python-uvloop process which is run from a container and spawns child processes. If those child processes spawn their own children which lose their parents (eg. via demonize()) then there's no way to reap them (as PID1 is honour-bound to do). I had been addressing this by patching libuv to do something analagous to FastChildWatcher - ie. reap all process in SIGCHLD handler. But this isn't really safe and can interfere with other libraries or modules (eg. a synchronous process start in another python module).
In the mean time, Python itself has deprecated child-watchers and is now using pidfd on Linux, and a dedicated wait() thread in all other cases.
This means that PID-1 programs can just install their own SIGCHLD handler to reap orphaned processes.
I was wondering if my proposal over on libuv/libuv#4179 might be of interest here? The idea would be to pass a special flag to libuv to tell it not to install a signal handler, and then use the python child watchers to handle reaping of libuv spawned processes.
Without this, a python process which sets up a SIGCHLD handler is going to break if switching from asyncio to uvloop (ie. the switch is no longer transparent, as of python 3.12)
- Lingua principale
- Cython
- Stelle
- 11.9k
- Fork
- 615
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
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 MagicStack/uvloop
-
License not clear Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
MagicStack/uvloop#759 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
MagicStack/uvloop#741 · 2 reazioni ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
MagicStack/uvloop#702 · 8 commenti · 9 reazioni ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
MagicStack/uvloop#766 ·
-
Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
MagicStack/uvloop#765 ·
Tutte le issue di MagicStack/uvloop
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
canonical/paas-charm#368 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
tech debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
area:workflow bug ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
fil-donadoni/tolaria#4409 ·
-
status/awaiting_triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100