
Von meinem iPad gesendet
Am 16.01.2018 um 08:00 schrieb Stefan Schwarzer <sschwarzer@sschwarzer.net>:
On 2018-01-15 20:55, Sven R. Kunze wrote: On 15.01.2018 17:07, Diez B. Roggisch wrote:
On 15. Jan 2018, at 16:46, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Was ist aus deiner Sicht das, was alle nehmen? Ich rate mal: asyncio. Die Chance, das du zB http-clients da einfach einpluggen kannst, und damit schon auf einem deutlich besseren Abstraktionsniveau unterwegs bist, als mit rohen Filedeskriptoren und epoll zu arbeiten laesst mich vermuten, dass es sich dabei um das Alufelgenrad handelt.
Diez
Aus meiner Sicht gequilter Unsinn. asyncio is ein Nischenprodukt und alle Welt verwendet File-Deskriptoren. Wunschdenken sollte nicht mit der Realität verwechseln werden.
Disclaimer: Ich habe bisher keine praktische Erfahrung mit Pythons asyncio-Framework, aber verstehe auf einem relativ abstrakten Niveau, wie `async` und `await` verwendet werden. Ich habe einige Erfahrung mit asynchronen Code in Twisted.
Ich bin auch eher skeptisch, was asyncio angeht:
- Ich finde die `async`s und `await`s im Code unübersichtlich.
- Man muss sehr aufpassen, dass man nicht versehentlich synchron laufenden Code dazwischen hat. Siehe zum Beispiel https://whatisjasongoldstein.com/writing/im-too-stupid-for-asyncio/ In dem Fall funktioniert der Code zwar "im Prinzip" noch, aber die Nebenläufigkeit geht teilweise verloren.
Ist ein Bug. Ich halte das im Vergleich zu Races in MT Umgebungen nicht für schlimmer.
- Durch mehrere Anläufe zu einer asyncio-API in Python ist die Sammlung dieser APIs sehr unübersichtlich geworden, siehe auch http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
- Es ist hakelig, synchronen Code in einem asynchronen Kontext zu verwenden und umgekehrt.
- Ich vermute, dass das Nachdenken über solchen Code und vor allem das Debuggen kein Vergnügen ist.
Wie sind da eure Erfahrungen?
Threaded Code ist da ja auch notorisch schwierig. Bestimmte Races verschwinden schon, wenn man nur Print statements oder anderes Logging einbaut. Etc.
_Je nach Anwendungsfall_ gibt es diverse Alternativen. Mir fallen spontan ein:
- `concurrent.futures`, quasi ein Pool von Threads oder Prozessen, aber mit einer nützlichen API zum Zugriff auf die Ergebnisse. https://docs.python.org/3/library/concurrent.futures.html
Wo genau der Unterschied zwischen einem Executor und einem Mainloop ist, insbesondere wenn man bei den Futures eine completion callback angibt, ist kaum erkennbar.
- Worker-Threads, die über Queues kommunizieren. Keine Objekte aus keinem Thread verändern, wenn sie erst mal in einer Queue sind oder waren! Das gilt analog auch für Shared State mit dem Threadpool-Executor aus `concurrent.futures`.
- "Kleine" Prozesse, die über einen Broker (zum Beispiel RabbitMQ) kommunizieren. Diese Prozesse entsprechen in etwa den Worker-Threads aus dem vorherigen Punkt.
Das ist ja erstmal komplett unabhängig davon, wie du deine Anwendung selbst strukturierst. Auf deine Arbeitsaufträge aus der Queue kannst du genauso asynchron warten. Ich will hier asyncio nicht über den grünen Klee loben. Aber ich sehe viel gefrickelten Code, der mit Queues und Threads genau das nachbaut, was einem ein eventloop wie asyncio einem schon gibt. Und dann vernünftig. Von wegen not invented here.... Die Frage ist meines Erachtens, ob die eingeführten Sprachkonstrukte es erlauben klareren Code zu schreiben, als das asynchrone Paradigma vorher mit callbacks und deferrables erfordert hat. Finde ich, ja. Und den Wert asynchroner Programmierung bezüglich Skalierung und Resourcenverbrauch belegen Server wie NGINX. LG Diez
Mit den ersten beiden Ansätzen habe ich selbst gearbeitet, den dritten Ansatz habe ich in einem Projekt, in dem ich mitgearbeitet habe, im Einsatz gesehen.
Was fällt euch an weiteren Ansätzen ein?
Natürlich hat man immer noch die grundlegenden Probleme von Nebenläufigkeit, aber mir gefällt, dass hier die "Bausteine" aus relativ viel synchronem Code bestehen, der sich größtenteils getrennt testen und debuggen lässt.
Was man aus meiner Sicht möglichst vermeiden sollte, ist, mit Low-Level-APIs zu hantieren, siehe auch https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf Das ist ein alter Artikel, der aber meiner Meinung nach die Tücken solcher APIs nach wie vor gut erläutert.
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de