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

[Stefan Schwarzer]

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 at 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