[Python-de] select.epoll() vs async framework (PostgreSQL)

[Sven R. Kunze]

On 18.01.2018 21:31, Achim Domma wrote:
> Würde ich nur solchen Code zu sehen bekommen, ginge es mir wohl wie dir.
> Von daher kann ich jetzt zumindest deine "Begeisterung" für asyncio
> verstehen. ;-)

:)

Mir ist in erster Linie wichtig, dass es funktioniert. Voreilige 
Optimierungen habe ich schon zur Genüge gesehen. Dafür hat es schon zu 
oft geklemmt, weil jemand meinte besonders schlau sein zu müssen. Wenn's 
brennt, dann muss es geradeaus gehen.

Und im Endeffekt ist asyncio nichts anderes als eine Optimierung. Ich 
denke, da sind wir uns einig.

> Nein, async und await sind nicht unbedingt high-level, aber eine höhere
> Abstraktion als select().

Vielleicht hinkt der Vergleich auch etwas.

EventLoop.run_forever und while True: select(...) sind miteinander 
vergleichbar.

async/await haben kein wirkliches Pendant.

>> Anderenfalls würde ich gerne hören, wie sich die asyncio-Gemeinde die
>> Lösung des Zwei-Welten-Problems vorstellt. Zum Beispiel anhand von WSGI.
> Meinst du mit Zwei-Welten-Problem das Problem, den Übergang von asnyc
> Code zu sync bzw. umgekehrt? Exakt das löst async/await in meinen Augen
> exakt so gut, wie es in Python auf Grund der Natur der Sprache eben
> geht. Die zwei Welten sind nunmal unterschiedlich.

Na, das würde ich nicht so unterschreiben wollen.

Deswegen auch das Beispiel mit dem WSGI. Richtig altmodisch klassisch 
hat man da einen Apache, der 20 WSGI-Worker mit Django zum Beispiel 
moderiert. Jeder Worker läuft in einem separatem Prozess. Dateien 
liefert der Apache alleine über eine entsprechende Kernel-Schnittstelle 
aus. Die Datenbank ist angebunden, 1 Worker 1 Connection üblicherweise. 
Wenn die Datenbank-Anfrage länger dauert, ist der Worker blockiert und 
kann keine anderen Anfragen beantworten. Es kann auch 10 bis 100 
DB-Anfragen für einen WSGI-Request erfolgen, oder auch mal 10.000, wenn 
der Programmierer Mist gebaut hat. :D

Jetzt die blöden Fragen:

- wie fummelt man da asyncio hinein? Ich fürchte, das würde überhaupt 
nicht gehen. "Mal eben ausprobieren" wird hart.
- *was wäre eigentlich die Zielsetzung?*
Angenommen, man hätte das doch irgendwie geschafft:
- wie stellt man sicher, dass, wenn die Abarbeitung eines Requests 
furios in, z.B., einem MemoryError scheitert, nicht auf einmal die 
anderen 100 Anfragen den Bach runtergehen?
- wie stellt man sicher, dass nicht 1 fehlerhaft implementierter View 
(das ist das Ding, was für einen Request eine Response erarbeitet), alle 
anderen 100 Anfragen blockiert - await vergessen, oder so?


Die Nachteile kooperativen Multitaskings bleiben bestehen, auch wenn 
diese totgeschwiegen werden. ;-)


Ich kann mir gut vorstellen, dass asyncio bei einem kleinen, niedlichen, 
perfekt abgeschlossenen Projekt, wie einem HTTP-File-Server (wie z.B. 
nginx) super gut funktioniert. Da ist alles gut abgestimmt, niemand 
tritt sich gegenseitig auf die Füße und es gibt eig. nur 1 Funktion -> 
serve_file.
Aber die meisten Web-Anwendungen, die Geschäftslogiken abbilden, sind 
dann doch eher ziemlich kompliziert/komplex und müssen ständig erweitert 
werden, wo ich mir gut vorstellen kann, dass man sich mit kooperativen 
Multitasking ziemlich sicher ins Knie schießt; auch je größer das Team 
wird. Da fehlen mir die Sicherungsmaßnahmen, die man bei einem separaten 
Prozess einfach hat.

> Klar kannst du eine
> Sprache wie Go (bezogen auf deine andere Nachricht) explizit für das
> Szenario designen.

Ich hoffe ja noch immer bisschen auf golang-Einfluss. :D Aber bei vielen 
hier steht da noch das Ego im Weg.

> Der Hauptkritikpunkt, den ich gelten lassen würde, ist, daß in den
> meisten Beispielen eben exakt der Übergang ausgespart wird. Ich hab' mir
> beim ersten mal auch den Wolf gesucht, bis ich die richtigen Funktionen
> zur Hand hatte. Und um sie zu benutzen, muß man schon ein solides Bild
> davon haben, was da passiert.

Ist man von Python eben nicht gewöhnt. So etwas fühlt sich dann an, wie 
wenn man von Python Ganzzahlen zu C int32 wechseln muss.

> Nochmal mein Fazit: Ich halte async/await für die beste Abstraktion, die
> in Python geht.

Ich würde diese Aussage insoweit relativieren, dass es zur Zeit als die 
von vielen beste Abstraktion angesehen wird.


Sven