Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Diez B. Roggisch" <deets@web.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] asyncio (was: Re: select.epoll() vs async framework (PostgreSQL))
Date: Tue, 16 Jan 2018 22:47:06 +0100
Lines: 128
Message-ID: <mailman.98.1516139229.2620.python-de@python.org>
References: <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <a1669a00-b66c-6cce-8546-570a857e77aa@behnel.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <a3efeeb7-3109-e01e-fe46-1fa032a06ba5@sschwarzer.net> <06D46350-4200-4E97-AB08-25F727F79A1A@web.de>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <a3efeeb7-3109-e01e-fe46-1fa032a06ba5@sschwarzer.net>
Precedence: list
Xref: csiph.com de.comp.lang.python:5077



Von meinem iPad gesendet

> Am 16.01.2018 um 08:00 schrieb Stefan Schwarzer <sschwarzer@sschwarzer.net=
>:
>=20
>> 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=C3=BCttler <guettliml@thomas-guettl=
er.de> wrote:
>>>>=20
>>>> Was ist aus deiner Sicht das, was alle nehmen?
>>> Ich rate mal: asyncio. Die Chance, das du zB http-clients da einfach ein=
pluggen kannst, und damit schon auf einem deutlich besseren Abstraktionsnive=
au unterwegs bist, als mit rohen Filedeskriptoren und epoll zu arbeiten laes=
st mich vermuten, dass es sich dabei um das Alufelgenrad handelt.
>>>=20
>>> Diez
>>=20
>> Aus meiner Sicht gequilter Unsinn. asyncio is ein Nischenprodukt und=20
>> alle Welt verwendet File-Deskriptoren. Wunschdenken sollte nicht mit der=20=

>> Realit=C3=A4t verwechseln werden.
>=20
> 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.
>=20
> Ich bin auch eher skeptisch, was asyncio angeht:
>=20
> - Ich finde die `async`s und `await`s im Code un=C3=BCbersichtlich.
>=20
> - 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=C3=A4ufigkeit geht teilweise verloren.

Ist ein Bug. Ich halte das im Vergleich zu Races in MT Umgebungen nicht f=C3=
=BCr schlimmer.=20
>=20
> - Durch mehrere Anl=C3=A4ufe zu einer asyncio-API in Python ist
>  die Sammlung dieser APIs sehr un=C3=BCbersichtlich geworden,
>  siehe auch
>  http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
>=20
> - Es ist hakelig, synchronen Code in einem asynchronen
>  Kontext zu verwenden und umgekehrt.
>=20
> - Ich vermute, dass das Nachdenken =C3=BCber solchen Code und vor
>  allem das Debuggen kein Vergn=C3=BCgen ist.
>=20
>  Wie sind da eure Erfahrungen?

Threaded Code ist da ja auch notorisch schwierig. Bestimmte Races verschwind=
en schon, wenn man nur Print statements oder anderes Logging einbaut. Etc.=20=

>=20
> _Je nach Anwendungsfall_ gibt es diverse Alternativen. Mir
> fallen spontan ein:
>=20
> - `concurrent.futures`, quasi ein Pool von Threads oder
>  Prozessen, aber mit einer n=C3=BCtzlichen 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, ins=
besondere wenn man bei den Futures eine completion callback angibt, ist kaum=
 erkennbar.=20

>=20
> - Worker-Threads, die =C3=BCber Queues kommunizieren. Keine
>  Objekte aus keinem Thread ver=C3=A4ndern, wenn sie erst mal
>  in einer Queue sind oder waren! Das gilt analog auch f=C3=BCr
>  Shared State mit dem Threadpool-Executor aus
>  `concurrent.futures`.
>=20
> - "Kleine" Prozesse, die =C3=BCber einen Broker (zum Beispiel
>  RabbitMQ) kommunizieren. Diese Prozesse entsprechen in
>  etwa den Worker-Threads aus dem vorherigen Punkt.

Das ist ja erstmal komplett unabh=C3=A4ngig davon, wie du deine Anwendung se=
lbst strukturierst. Auf deine Arbeitsauftr=C3=A4ge aus der Queue kannst du g=
enauso asynchron warten.=20

Ich will hier asyncio nicht =C3=BCber den gr=C3=BCnen Klee loben. Aber ich s=
ehe viel gefrickelten Code, der mit Queues und Threads genau das nachbaut, w=
as einem ein eventloop wie asyncio einem schon gibt. Und dann vern=C3=BCnfti=
g. Von wegen not invented here....

Die Frage ist meines Erachtens, ob die eingef=C3=BChrten Sprachkonstrukte es=
 erlauben klareren Code zu schreiben, als das asynchrone Paradigma vorher mi=
t callbacks und deferrables erfordert hat. Finde ich, ja.=20

Und den Wert asynchroner Programmierung bez=C3=BCglich Skalierung und Resour=
cenverbrauch belegen Server wie NGINX.


LG Diez=20


>=20
> Mit den ersten beiden Ans=C3=A4tzen habe ich selbst gearbeitet,
> den dritten Ansatz habe ich in einem Projekt, in dem ich
> mitgearbeitet habe, im Einsatz gesehen.
>=20
> Was f=C3=A4llt euch an weiteren Ans=C3=A4tzen ein?
>=20
> Nat=C3=BCrlich hat man immer noch die grundlegenden Probleme
> von Nebenl=C3=A4ufigkeit, aber mir gef=C3=A4llt, dass hier die
> "Bausteine" aus relativ viel synchronem Code bestehen,
> der sich gr=C3=B6=C3=9Ftenteils getrennt testen und debuggen l=C3=A4sst.
>=20
> Was man aus meiner Sicht m=C3=B6glichst 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=C3=BCcken solcher APIs nach wie vor gut erl=C3=A4utert.
>=20
> Viele Gr=C3=BC=C3=9Fe
> Stefan
> _______________________________________________
> python-de maillist  -  python-de@python.org
> https://mail.python.org/mailman/listinfo/python-de
>=20