pipes from subprocess_exec do not have extra info 'pipe' (incompatible with vanilla asyncio)
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- python
- Bereich
- backend, networking
Rechercherichtung
Beginne im UVProcessTransport-Code an der Stelle, an der der WriteUnixTransport für Subprozess-Pipes erstellt wird, und vergleiche ihn mit loop.create_write_pipe(), das die zusätzlichen Pipe-Informationen hinzufügt. Überprüfe, dass der von get_pipe_transport() zurückgegebene Subprozess-stdin-Transport die zugrunde liegende Pipe über get_extra_info('pipe') bereitstellt und damit dem Verhalten von vanilla asyncio entspricht.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
-
uvloop version:
0.19.0 -
Python version:
3.10.12 -
Platform:
linux -
Can you reproduce the bug with
PYTHONASYNCIODEBUGin env?:
yes -
Does uvloop behave differently from vanilla asyncio? How?:
Yes, this is the point of this issue report. So after you get your process transport from subprocess_exec(...) you then can use get_pipe_transport() to access the transport associated with stdin. With vanilla asyncio you can then call get_extra_info('pipe') on that transport to access the pipe directly. With uvloop get_extra_info('pipe') on the same transport returns None.
I can see in the source that when a pipe transport is created via loop.create_write_pipe(...) we have:
transp = WriteUnixTransport.new(self, proto, None, waiter)
transp._add_extra_info('pipe', pipe)
However no transp._add_extra_info(...) is done on the WriteUnixTransport that is created inside the UVProcessTransport code. There are ways to work around this (don't depend on getting access to that pipe) however this works fine in the asyncio loop implementation. I imagine it can be done without too much pain by wrapping the raw file descriptor created in the process transport code however I'm not super fluent in cython so I didn't attempt a patch.
- 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 ·