Idea: changing libuv not to install a signal handler
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- linux, python
- Bereich
- backend, operating-systems
Rechercherichtung
Beginne damit, die vorgeschlagene Änderung in libuv/libuv#4179 zu prüfen und zu untersuchen, wie uvloop derzeit libuv für die Behandlung von Child-Prozessen und Signalen nutzt. Vergleiche dieses Verhalten mit den Child-Watchern von Python, der pidfd-Unterstützung unter Linux und dedizierten Wait-Threads an anderer Stelle; die Aufgabe wäre erst erledigt, wenn ein festgelegtes, sicheres Integrationsdesign mit geeigneten Tests vorliegt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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)
- Vorherrschende Sprache
- Cython
- Sterne
- 11.9k
- Forks
- 615
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus MagicStack/uvloop
-
License not clear Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
MagicStack/uvloop#759 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
MagicStack/uvloop#741 · 2 Reaktionen ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
MagicStack/uvloop#702 · 8 Kommentare · 9 Reaktionen ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
MagicStack/uvloop#766 ·
-
Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
MagicStack/uvloop#765 ·
Alle Issues in MagicStack/uvloop
Ähnliche Issues
-
Area: Excel support
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
orbeon/orbeon-forms#7893 ·
-
essnmx good first issue
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 95/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
yeti-platform/yeti#1380 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
modelcontextprotocol/python-sdk#3566 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
griptape-ai/griptape#2353 ·