Implementácia async v pythone z alternatívneho vesmíru

23.8. 14:16 | Přečteno: 1607× | Programovanie | | poslední úprava: 23.8. 14:15

Už je to okrúhlych 10 rokov od kedy python má podporu asynchrónneho programovania. Tento článok z alternatívneho vesmíru nám ukáže ako mohol vyzerať python ak by sa vydal trocha inou cestou.

Už okolo roku 2010 začalo byť jasné, že budúcnosť webových aplikácií patrí dlho bežiacim socketom. Tradičné formy konkurentného behu ako procesy a vlákna boli pre tento účel príliš ťažké a tak sa oprášil starý koncept kooperatívneho multitaskingu používaný v operačných systémoch v minulom tisícročí.

Do úvahy sa brali rôzne alternatívy ako napríklad zavedenie kľúčových slov async a await, čo je inak povedané farbenie funkcií. V praxi by to znamenalo, že každá knižnica, každý kód, ktorý by mal podporovať súčasné blokujúce API a zároveň asynchrónne API by musel implementovať oba. Znamenalo by to duplikáciu kódu skoro celého python ekosystému a to nikto nechcel.

Väčšina sync / async funkcií sa v praxi líši len farbou a jedným volaním. Ak by sa python vydal touto cestou, určite by vznikli rôzne automatizované nástroje ako tento vtip menom unasync.

Určite by veľké frameworky ako Django mali problémy, ktoré by sa preberali v dlhých diskusiách.

Existovali by problémy s async property, pretože by nebolo možné sprístupniť ORM related model ako book.author ktorý by bol synchrónny alebo asynchrónny keď to, či pristupuje k databáze závisí od toho, či bol dotaz volaný so select_related (žiaden prístup), prefetch_related (prístup pri prvom objekte v iterácii), alebo prístup v každom objekte. Jednoducho s async / await by to bol veľký chaos, ktorý by roky trápil a rozdeľoval komunitu.

Ako funguje bez farbenia a nových kľúčových slov?

Každá blokujúca I/O operácia implementovaná v pythone má svoju sync a async variantu. Tá sa volí podľa kontextu, v ktorom je spustená.

Aby program bežal kooperatívne postačuje, aby kooperatívna časť bola spustená ako CooperativeThread. API zostáva kompatibilné so systémovými vláknami, ale spracovanie udalostí CooperativeThread sa uskutočňuje buď v implicitnom event-loope, alebo vo vlastnom loope explicitne poslanom konštruktoru CooperativeThread.

Toto jednoduché rozšírenie pythonu prinieslo kooperatívny multitasking aj do starého kódu bez akejkoľvek nutnosti upraviť kód. Knižnice sa stali automaticky kooperatívnymi v momente keď sa spustili v správnom kontexte. Netreba nič prepisovať, len doplniť malú časť do pythonu. Všetko ostatné je zadarmo.

Je toto vôbec legálne?

Ak sa pýtate, či je to v súlade s python Zen tak nie:

Explicit is better than implicit.

Niekedy si radšej zababrem ruky za lepšie riešenie než by som sa striktne držal pravidiel.

       

Komentáře

[vencour]

🐧 +1

[Bystroushaak]

Mi to připomíná Stackless a jak dřív fungoval async přes Twisted.

Přijde mi ale že hlavní problém jsou ty různé barvy, což tak nějak plyne z toho že nejde pustit jedno jako druhé, kde je správná otázka; proč ne? A co by se muselo udělat aby to šlo? Jakože zkompilovat alt verzi sync bytekódu kde nasereš await / async všude kde to jde?

[mirec]

Myšlienka je nehanebne vykradnutá z Java virtual threads. Nerád to priznávam, ale Java predsalen niečo urobila dobre. Alebo som už starý a väčšina mozgových buniek mi už odumrela a preto tajne obdivujem Javu. Videl som snahu o await anywhere, čo by problém do istej miery riešilo - cpython-await-anywhere. No a nakoniec existuje ešte celá veľká diskusia o virtual threads.

Tie farby sú hlavne v Djagngo problém a nadávam na to od rána do večera. Transakcie s tým nefungujú. Všetky async db funkcie sú implementované tak, že sa spúšťajú synchrónne v jednom vlákne s neskutočnou réžiou jedného async volania okolo 1ms. Nie je to rýchlejšie ani o chlp a všetko okolo je proste nepodarený vtip. Stackless, twisted aj gevent poznám. Geventu som tak trocha držal palce, že nektoré myšlienky by mohli byť zapracované (ale nie ako monkey patch).

[Bystroushaak]

Tie farby sú hlavne v Djagngo problém a nadávam na to od rána do večera. Transakcie s tým nefungujú. Všetky async db funkcie sú implementované tak, že sa spúšťajú synchrónne v jednom vlákne s neskutočnou réžiou jedného async volania okolo 1ms. Nie je to rýchlejšie ani o chlp a všetko okolo je proste nepodarený vtip.

Jo, já vím. Taky mám jeden sync kód kde tohle musím volat pro každý uživatelský požadavek (flask) na grpc service, protože ten tým co píše tu service zveřejňuje jen async balík a je to fakt oser.

U nás jedem všechno sync + mutltithreading / multiprocessing, tak nějak to dělá můj život snažším, i když to má pár nevýhod. Co mě zaráží je kolik lídí v mém okolí často přijde s tím že "pojďme to přepsat na async, bude to lepší" a pak nejsou schopni odpovědět jak.

Lehce unrelated; nedávno někdo posílal https://github.com/Dicklesworthstone/asupersync, to vypadá docela cool.

Ještě mnohem víc unrelated a cool: Tohle doporučuji Computer System Organization: The B5700/B6700 Series, je to docela krátké a překvapivě relevantní i dneska. Čuměl jsem jak moc z toho používáme a byl překvapen jak moc ne, hlavně co se týče paralelizace a synchronizace procesů.

[mirec]

Dik za linky, pozriem si.

Nemám kolegov, s ktorými by som preberal takéto technické veci, ale keď vidím v internetových diskusiách ako všetci nadšene tlieskajú nápadom prepíšme to všetko do async tak len krútim hlavou. Ľudia nechápu tomu, čo je kooperatívny multitasking a ako málo sa z toho dá vyťažiť ak práve nerobia náhodou multi user chat s tisícmi aktívnych websocket spojení, lenže to je niečo dosť špecifické.

[RealJ]

ja Java neobdivuji tajne, ja kdykoliv mam napsat neco vetsiho nez Alesove 3 skripty tak volim Java. Funguje to vicemene vsude na intelu, armu, atd., programovani pro vice cpu/cores je ve srovnani s jinymi jazyky snadne, ... ja doted nejak nepobral proc lidi nad java remcaj, prijde mi to jako vykriky o tom jak je heterosexualita mrtva a musis bejt minimalne cernej gay aby jsi mohl nekde pracovat...

[mirec]

V dobe AI aj súhlasím, že Java je dobrá. V dobe pred AI som silne preferoval jazyky, ktoré umožňujú jednoducho špinavým spôsobom implementovať veľa na málo riadkoch kódu. Ľahšie sa to píše a hlavne ľahšie sa to číta. Návrhové vzory? Meh. Singleton? Meh, bac niečo do modulu. Ochrana? Meh. Sme dospelí. Až sa budem hrať so zápalkami viem čo sa stane. Teraz väčšina ľudí mávne rukou nad riadkami. Keď niekedy prepisujem 50-riadkový AI python kód na 20 riadkový pripadám si ako dinosaurus. Na rozdiel od samotného jazyka Java mám Java VM veľmi rád a myslím, že je celkom lightweight. Taktiež memory overhead nie je tak hrozný keď si človek uvedomí, že typické C po mallocu a free fragmentuje.

[RealJ]

V dobe pred AI som silne preferoval jazyky, ktoré umožňujú jednoducho špinavým spôsobom implementovať veľa na málo riadkoch kódu - no ale to java umoznuje. Asi zalezi co implementujes, ja delal veci kolem smart cards (a vse co ma nejakej embeded chip) a tam v java udelas na 2k radcich to co v jinem jazyce budes psat mesice.
Keď niekedy prepisujem 50-riadkový AI python kód na 20 riadkový pripadám si ako dinosaurus - to je zasadni chyba, neprepisuj, dej to agentovi at to prepise a optimalizuje. Ja takhle optimalizoval kod ktery po nekolika verzich delal neco 5 minut, codex ho v nekolika sessions optimalizoval na 0.5s.

[mirec]

Dať to agentovi to neviem, lebo neviem, čo je cieľ. Chcem čitateľný krátky nie overengineered kód, ale agent nerozumie. Agent spraví. Ja nerozumiem. Agent ukecaný. Ja nie. Ja priamy. Hack hack done.

[RealJ]

kdyz nevis co je cil jak to pak prepisujes ty? Obvykle mam cil treba at to bezi rychlejc, nebo at je to min Alesovina... jinak kdyz reknes agentovi svou diagnozu a at se prizpusobi tak to umi taky...

[mirec]

Cieľ je aby to vedel zmeniť / opraviť / prečítať človek. Vidím zložitý algoritmus a myslím, že nemusí byť zložitý. Prepíšem ho. Okrem toho väčšinou píšem v pythone takže málo balastu a väčšinou mi ručný zásah zaberie menej času než vysvetľovať čo presne chcem.

[Mirkob]

...a tam v java udelas na 2k radcich to co v jinem jazyce budes psat mesice.

Tak jiste, protoze vsechnu spinavou pracu nakonec oddre nejaka knihovna v jinem jazyce, nejspis C, nad kterou jen nad vsemi vrstvami pripises jeste jednu v Jave.
Prenositelnost programu v Jave je pak nanejvys takova, jako je prunik vsech tech knihoven na spinavou praci, ktere jsi Javou slepil dohromady, pokud ovsem tech svych 2K radek nenaprasis tak, ze to pobezi jen na Windows, a to jeste jen za uplnku a pokud v Pacifiku nebude motyl mavat kridly.
Proto je Java zlocinna, skodliva, zpusobuje poskozeni mozku a nikdo by ji nemel pouzivat.

[xkucf03]

s/Java/Python/g

Takhle se právě programuje v Pythonu – výkonný kód je v nativních knihovnách, často nepřenositelný a křehký. A kód v Pythonu je jen vrstva lepidla nad tím. V Javě je naopak běžné implementovat knihovny v čisté Javě. Nativní se používají jen pro takové věci jako OpenGL nebo interakci s hardwarem. Ale i třeba kryptografii nebo síťové protokoly a de/kodéry formátů máš čistě v Javě (tzn. přehlednější a mj. bezpečnější než třeba nativní céčko).

[Mirkob]

Takhle se programuje nejen v Pythonu, ale predevsim v Jave, protoze lepit Javou dalsi Javu...Jiste, spousta lidi si mysli, ze dokaze napsat znovu a lepe (navic v Jave, lol) to, co jiz resi nejaka knihovna v Ccku. Vetsina se seredne pletne (protoze Dunning–Kruger).

[RealJ]

njn, knihovny v Ccku resi kde co ale taky spoustu veci neresi a pak jsi v situaci kdy ta java umi vice za min casu...

[RealJ]

ja ve spouste veci knihovny nepouzivam protoze me nebavi resit bordel s nima a udrzovat je pak u zivota i kdyz umrou... ja windows moc nepouzivam, mam ho na par virtualech kdyz neco potrebuji odtestovat ale jinak moc ne... ja myslim ze ti java neco udelala, patrne ti vystrilela oblibenou hospodu, nebo tak neco...

[Xerces]

Hoši vy jste renegádi! Linuxák a obdivuje Javu. Dělá se mi mdlo při představě v tom něco kódovat. Aplikace, která dotahuje jako závislost JRE je pro mě red flag.

[Want]

Ten patla matla Žako není žádný linuxák. Jenom pták.

[RealJ]

presne tak, oznaceni linuxak ti klidne prenecham..

[RealJ]

hele, ja to mel stejne az jsem potreboval resit prenositelnost... to zjistis ze spousta veci v ruznych jazycich je tak nejak prenositelna, ale potrebujes resit spoustu veci kolem. Pokud mas 1-2 architektury tak to nemusis nejak resit, pokud chces resit 10-15 architektur tak podle me aktualne nic snadnejsiho nez java neni. Pokud ale delas v korporatu, tvuj zivot je na windows nebo linux tak ten red flag samozrejme chapu.

[luky]

Poslednich 15 let vyvijim a udrzuju kod v C, ktery bezi na 6 ruznejch architecturach a stalo se mi asi 3x, ze jsem musel kod upravovat kvuli prenositelnosti. Jasne, v dobe vzniku javy to bylo jinak, ale dnes by clovek musel vylozene prasit aby v C napsal neprenositelnej kod.

[xkucf03]

Ta multiplatformnost není jediná výhoda. Jde i o paměťovou bezpečnost, objektově orientované programování, generika, anotace atd. Ale chápu, že mezi Javou a C není moc překryv, každé se hodí na něco jiného, takže pokud pro tvoje programy vyhovuje C, nemá cenu ti nabízet Javu.

[luky]

Moje poznamka byla o tom, ze argument lepsi prenositelnosti javy oproti modernimu C je blabol. Jedna z platforem, pro kterou vyvijim, je big-endian mip64, kterej snad nikdy ani javu nemel. OpenJDK podporovalo little-endian a Sun/Oracle port pro mips nikdy nevydal.

[RealJ]

ja v zasade s tebou souhlasim, Ccko ma skvelou prenositelnost... predpokladam, ze pises pro sitovej hw a tam to dava smysl hlavne kvuli rychlosti...

[luky]

Ano, sitarina a trochu rizeni. Kde je potreba vykon, je to v C, kde ne tak v Pythonu (UI a tak).

[tom1]

Pro používání async kdekoliv není potřeba ani fork pythonu: https://github.com/tzolkincz/colorblind-async

[vlk]

select.poll() rulez - stara skola - ziadne farby ani nic, proste to funguje. mam rad jednoduchy jednosluckovy kod nez sa hrabat v asynchronne beziacich funkciach, casto sa v tom clovek dokaze stratit ,-)

[xkucf03]

Ještě epoll je dobrý. Jinak souhlas. Dneska je bohužel tendence psát asynchronně a nepřehledně i kód, kde to nemá opodstatnění a reálně to nic nepřináší.

[vlk]

ano, epoll() linux, alebo kqueue() bsd - dalsie triestenie ktore snad nikdy nepochopim. + select.select() - na tak zasadnej veci sa sa nedokazali dohodnut, kazdy kopiruje ale tuto dolezitu vec linux skopirovat nevedel. a najhorsie je to, ze tuto zakladnu vec vobec nereimplementovali priamo do klasickeho poll() ale musim riesit platformu na ktorej kompilujem alebo pouzivat kniznice ako selectors

[xkucf03]

Existuje epoll-shim, který přináší epoll do BSD. Ten epoll je výrazně pohodlnější než surový select.

[jbv]

select.poll má lineární složitost, takže už je desítky let lepší se mu vyhnout (např. použít epoll). Neschopnost místních "programátorů" mě nepřestává udivovat

[vlk]

klaniam sa vam pan programator! lebo vobec som nikdy nepocul nic o epoll a kqueue

[jbv]

Jasný dědku, nejdřív si vzpomeň cos napsal

select.poll() rulez - stara skola - ziadne farby ani nic, proste to funguje. mam rad jednoduchy jednosluckovy kod nez sa hrabat v asynchronne beziacich funkciach, casto sa v tom clovek dokaze stratit ,-)

Ale beze srandy, chápu, že už to pro tebe neni, tak prosím nenavrhuj jak se to má dělat teď, jo?

[luky]

Ja jsem asi pred 18 lety naprogramoval PoC aplikaci pres perlovske coro, s tim, ze pokud se architectura osvedci, prepise se to do neceho jineho. Vloni jsem se dozvedel, ze to porad pouzivaj a nikdy to neprepsali

[RealJ]

njn, ja pred 100 lety napsal neco ve foxpro a furt to bezi... no a skladove hospodarstvi v access 2.0 ktere jsem taky jednou napsal pry taky furt bezi... :D

[Want]

A taky ses tu svého času kasal, jak vyděláváš na WordPressu

[RealJ]

si to pletes Alesi, ja psal ze za $1 mesicne WordPress je skvela volba..

[Want]

Proč lžeš?

[luky]

Tak ja to uvedl proto, ze to coro funguje vpodstate tak, jak je popsano v blogu.

[jbv]

Toto jednoduché rozšírenie pythonu prinieslo kooperatívny multitasking aj do starého kódu bez akejkoľvek nutnosti upraviť kód.

Tohle mi přijde jako extrémně optimistické tvrzení. IMHO tenhle přístup obecně povede jen ke zvýšení latencí a bude potřeba celý kód přepsat. Pokud jseš ty, kdo rozhoduje o kontext switchi, tak prostě musíš zajistit, že nesedíš na CPU moc dlouho, jinak brzdíš ostatní. V synchronním kódu to za tebe řeší někdo jiný, ale v async kódu je to na tobě. Proto i když je to otravný, tak dává smysl funkce barvit, protože sémantika je jiná.

[mirec]

Tvrdenie nie je optimistické a reálny rozdiel nemusí byť merateľný. Kontrola na úrovni volania nemusí existovať. V momente keď posielam funkciu CooperativeThread môže python urobiť runtime špecializáciu funkcie (1 volania za celý beh programu), ktorý ju špecializuje na stackless / async so sémantikou kódu bez farbenia.

[jbv]

Já se neptám na implementaci toho runtime co navrhuješ. Ale toho jak se bude chovat reálný kód psaný klienty tvého teoretického API. Napsali program pro sync a teď ho pustí asynchronně. A v tu chvíli se diví, jak se to chová, protože vůbec nepočítali se změnou sémantiky jednotlivých příkazů. Najednou když zavolám 5 IO operací sériově místo paralelně, tak to trvá 100x tak dlouho, protože soupeří o čas s ostatníma špatně napsanýma korutinama. Takhle totiž dopadnou naivní přepisy sync do async. Async programování není o větším výkonu, ale o lepším využití zdrojů. Projeví se to na extrémním high performance nebo v cloudu, kde je typicky i disk je síťový, takže IO je brutálně pomalý (pokud máš lokální disk a pár stovek rps na http, tak snadno můžeš zjistit, že async programování v pythonu vůbec nepotřebuješ).

[mirec]

Ja som tu nebol ten, kto písal o latencii a výkone. Plne chápem, že async je pre mňa dobrý ak musím držať tisíce otvorených spojení a nemá to nič spoločné s výkonom. Toto mi vážne netreba vysvetľovať. Teraz píšem aplikáciu v async frameworku (FastAPI) a mám chuť niekoho nakopať za ten návrh. Všetko musím farbiť aj keď nikde reálne nedržím spojenia. Pretože niekto rozhodol, že async je lepší. Java s virtual threads to dokázala implementovať a čuduj sa svete nie nie je to 100x pomalšie než 1 sériové vlákno. Ak sa bavíme o výkone tak sa musíme baviť o implementácii, lebo výkon závisí od implementácie. Ak to bude implementované dobre, nebude to 100x pomalšie než 1 sériové vlákno. Rozdiel bude odhadom v jednotkách % oproti natívnom async.

[jbv]

Pokud nemáš žádné IO, tak proč to píšeš asynchronně? Nebo snad musí být všechno ve FastAPI? V mých projektech mám FastAPI tak v polovině případů kde to dává smysl. Ano je oser rozchodit si všechny ty super věci okolo (routování, swagger apod.), ale zrovna dělat API je celkem snadná věc i bez frameworků. Nebo když potřebuju výkon ještě líp použít rust, kde to díky hodně kvalitním knihovnám není moc práce navíc.

K tomu zbytku, pořád nechápeš, že v async světě řídí přepínání kontextu programátor, kdežto v threadech/procesech externí plánovač. Logicky ten kód nemůže být stejný a v async programování mnohem víc záleží na schopnostech aplikačního programátora. Když napíše kód, kde korutiny mají zásadně rozdílné časy běhu, tak jen narůstají latence bez ohledu na to jak kvalitní máš runtime.

Konkrétně k FastAPI dost záleží jaké "optional" knihovny použiješ. Např. uvloop nebo orjson dělají divy.

[mirec]

Ešte raz beh programu stačí prerušovať na miestach volania IO a to sa dá automaticky. Tak to robí java (samozrejme okrem iných) a evidentne to funguje ak sa IO nemieša s dlho bežiacim spracovaním.

[jbv]

Však o tom celou dobu mluvím, že v případě kooperativního přepínání kontextu musíš zajistit, že dlouhoběžící úlohy nezastaví event loop. A to obecně synchronní kód nesplňuje a proto je lepší varianta barvení. Jinak dostáváš kód, který sice není barvený, ale zato v sync nebo async kontextu nefunguje dobře. Takže ho stejně nemůžeš použít univerzálně.