Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #5078

Re: [Python-de] asyncio

Show all headers | View raw

On 2018-01-16 22:47, Diez B. Roggisch wrote:>> Am 16.01.2018 um 08:00 schrieb Stefan Schwarzer <sschwarzer@sschwarzer.net>:
>> - 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.
>
> Ist ein Bug. Ich halte das im Vergleich zu Races in MT Umgebungen nicht für schlimmer.

Ich glaube, hier spielt sehr stark mit rein, wie gut man (in
beiden Fällen) den Code verstehen und die Bugs vermeiden
oder beheben kann. Die "Gelegenheiten" für Race Conditions
sind  in Multithread- oder Multiprozess-basiertem Code sicher
häufiger und subtiler.

Race Conditions und Deadlocks kann man auch in asyncio-
Programmen haben, je nachdem ob/wie die nebenläufigen
Programmteile voneinander abhängen.

>> - 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?
>
> Threaded Code ist da ja auch notorisch schwierig. Bestimmte Races verschwinden schon, wenn man nur Print statements oder anderes Logging einbaut. Etc.

Das stimmt. Mich würden allerdings eher Erfahrungen mit
asyncio-Code interessieren, nicht mit multithreaded Code.
:-)

>> _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
>
> Wo genau der Unterschied zwischen einem Executor und einem Mainloop ist, insbesondere wenn man bei den Futures eine completion callback angibt, ist kaum erkennbar.

Ich vermeide Callbacks bei Futures (und auch sonst), wenn es
geht. Was ich dagegen sehr mag, ist der `as_completed`-Iterator,
https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.as_completed
Ich denke, diese vielleicht unscheinbare Funktion macht viel
für die "User Experience" aus.

> Die Frage ist meines Erachtens, ob die eingeführten Sprachkonstrukte es erlauben klareren Code zu schreiben, als das asynchrone Paradigma vorher mit callbacks und deferrables erfordert hat. Finde ich, ja.

Ich würde asyncio-Code ziemlich sicher Callback-basiertem
Code vorziehen. Aber der Punkt ist ja, ob bzw. unter welchen
Umständen es außer "asyncio mit Callbacks" und "asyncio mit
`async`/`await`" welche Alternativen gibt.

> Und den Wert asynchroner Programmierung bezüglich Skalierung und Resourcenverbrauch belegen Server wie NGINX.

Dass das prinzipiell funktioniert, ist klar. Die Frage ist
halt, wann ist es der "beste" Ansatz?

Ich glaube, mich persönlich stört am meisten, dass man
synchron geschriebenen Code und mit `async`/`await`
geschriebenen Code nicht gut verbinden kann. Beziehungsweise
das sieht immer irgendwie zusammengefrickelt aus.

Für mich sieht `async`/`await`-Code in Python quasi wie eine
andere Programmiersprache aus.

Viele Grüße
Stefan

Back to de.comp.lang.python | Previous | Next | Find similar

Thread

Re: [Python-de] asyncio Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2018-01-17 08:16 +0100

csiph-web