Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #5077

Re: [Python-de] asyncio (was: Re: select.epoll() vs async framework (PostgreSQL))

Show key headers only | View raw

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
> 

Back to de.comp.lang.python | Previous | Next | Find similar

Thread

Re: [Python-de] asyncio (was: Re: select.epoll() vs async framework (PostgreSQL)) "Diez B. Roggisch" <deets@web.de> - 2018-01-16 22:47 +0100

csiph-web