Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Dinu Gherman <gherman@darwin.in-berlin.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] asyncio (was: Re: select.epoll() vs async framework (PostgreSQL))
Date: Tue, 16 Jan 2018 08:39:48 +0100
Lines: 101
Message-ID: <mailman.77.1516088634.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> <9B6CCC7B-81CB-4DD1-81FA-D6C13EEDC600@darwin.in-berlin.de>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
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:5070

Ich empfehle mal zu dem Thema einen sehr informativen Vortrag von =
Raymond Heutiger, =E2=80=9EKeynote on Concurrency, PyBay 2017=E2=80=9C: =
https://www.youtube.com/watch?v=3D9zinZmE3Ogk

Gru=C3=9F,

Dinu

> 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-guettler.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 =
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.
>>>=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.
>=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?
>=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
>=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.
>=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