standardmäßig führt Asyncio Coroutinen synchron aus. Wenn sie blockierende IO -Code enthalten, warten sie immer noch darauf, dass es zurückkehrt. Ein Weg um diese Weise ist loop.run_in_executor () , der den Code in Threads umwandelt. Wenn ein Thread auf IO blockiert, kann ein weiterer Thread mit der Ausführung beginnen. Sie verschwenden also keine Zeit damit, auf IO -Anrufe zu warten. Also habe ich mich gefragt, warum Sie Executoren explizit verwenden müssen. Warum nicht standardmäßig aktivieren? Es handelt sich um eine Bibliothek, die im Wesentlichen eine Kombination aus Asyncio und Anforderungen : Nicht blockierende HTTP -Anrufe bietet. Asyncio und fordert so ziemlich wie aiohttp . Gibt es einen Grund, eine neue Bibliothek zu implementieren. Zahlen Sie eine Leistungsstrafe für die Verwendung von Ausführern? Es ist also sinnvoll, sie nicht als Standardverhalten zu haben. AIOHTTP ist besser als das Anforderungen in einem Executor, da es nicht blockierende Code mit nur Coroutinen bietet.
, was mich zu dieser Frage bringt. AIOHTTP wirbt sich als:
Asynchronous http Client/Server für Asyncio und Python. Warum bietet Asyncio dann nicht blockierende Code mit nur Coroutinen an? Das wäre der ideale Standard. Async/wartet sind eine Sprachfunktion. Asyncio ist eine Ereignisschleife. Und wenn AIOHTTP eine eigene Event-Loop hat, sollte es nur wenig Schnittpunkt zu Asyncio geben. Eigentlich würde ich argumentieren, dass eine solche Ereignisschleife eine viel größere Funktion wäre als HTTP -Anfragen.
Asyncio: Warum ist es nicht standardisch nicht blockiert? ⇐ Python
-
- Similar Topics
- Replies
- Views
- Last post