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

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

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

Show all headers | View raw

Ich empfehle mal zu dem Thema einen sehr informativen Vortrag von Raymond Heutiger, „Keynote on Concurrency, PyBay 2017“: https://www.youtube.com/watch?v=9zinZmE3Ogk

Gruß,

Dinu

> 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.
> 
> - 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?
> 
> _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
> 
> - 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.
> 
> 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)) Dinu Gherman <gherman@darwin.in-berlin.de> - 2018-01-16 08:39 +0100

csiph-web