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

[Stefan Behnel]

Sven R. Kunze schrieb am 15.01.2018 um 20:55:
> On 15.01.2018 17:07, Diez B. Roggisch wrote:
>>> On 15. Jan 2018, at 16:46, Thomas Güttler 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.
> 
> Aus meiner Sicht gequilter Unsinn. asyncio is ein Nischenprodukt und alle
> Welt verwendet File-Deskriptoren. Wunschdenken sollte nicht mit der
> Realität verwechseln werden.
> 
> Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau als
> meinen Quellcode überall mit diesem dämlichen async und await zu spicken.

Ich verstehe nicht, warum das ein Argument dafür sein sollte, sich seinen
eigenen I/O-Loop zu schreiben. AsyncIO wurde exakt und einzig und allein
aus dem Grund geschrieben, dass es bereits zu viele davon gab, die alle
nicht miteinander kompatibel waren. Wenn Thomas also jetzt darüber
nachdenkt, sein handgedrechseltes select() noch weiter zu einem solchen
auszubauen, dann nehme ich das als Anreiz, auf die vergleichbaren Fehler
anderer hinzuweisen, aus denen bereits nachhaltig Lehren gezogen wurden.

Ein hübsches Ergebnis ist jetzt z.B., dass das Tornado Web-Framework in der
Version 5 komplett auf asyncio umziehen wird und in der Folgeversion den
eigenen I/O-Loop über den Jordan jagt. Das große Aufräumen hat begonnen.

Und eine zweite Implementierung von asyncio gibt es mit uvloop auch schon,
so dass jetzt auf beiden Seiten der Schnittstelle die freie Auswahl
besteht. AsyncIO ist auf dem besten Weg, für die Welt des kooperativen
Multitaskings so etwas zu werden wie WSGI es seit Jahren schon für
synchrone Web-Frameworks ist.

Stefan