Vždyť async/await jsou právě taky jen korutiny, jen se zbytečně složitou syntaxí (proto to tolik lidí mate). Právě Go má v podstatě to samé, ale transparentně.
Asi podle toho, na jake urovni se na to divas. Async/await je hlavne cukr pro futures, zatimco goroutiny spis davaji pocit plne oddelenych vlaken provadeni - jako plnohodnotna OS vlakna. Implementacne to muze byt dost podobne, hlavne na urovni event loopu, ale ten koncept jako takovy je imho dost jiny - async/await je matouci a otravne, gorutiny jsou naprosto v pohode.
BTW scheduler v Go je kooperativní doposud, jede nad kqueue/IO ports apod. podle OS.
Dik. Mel jsem matny pocit, ze jsem nekde cetl, ze s tim cosi v posledni dobe delali. Bud se pletu, nebo to mozna byl nejaky plan pro Go 2? Nevim.
v provnání s vlákny
Ok. V porovnani s vlakny ale imho async/await samo o sobe negarantuje nemoznost race conditions. Porad je tam nejake prepinani kontextu, ke kteremu pri trose fantazie muze dojit v nevhodny okamzik. Tim spis, cim vic k tomu prepinani dochazi. Jestli je tam nejaky vyrazny rozdil oproti vlaknum, tak prave v tom, ze se prepina jenom v urcite okamziky, takze k race condition nemusi vubec nikdy dojit. To ale neni
garance, to je (vicemene)
nahoda, coz je mozna jeste horsi...
v tom jsou lepší jazyky, kde je asynchronní vše.
Bez diskuse. Vubec nechapu, proc Python touhle cestou nesel. Imho si tim pekne nabehl na vidle a co je horsi, potahne si tuhle zatez ssebou jeste pekne dlouho, protoze se z toho dost dobre ted uz neda vybrednout
Částečné řešení je volání sync variant blokujících funkcí v threadpoolu. https://docs.python.org/3/library/asyncio-eventloop.html#executing-code-in-thread-or-process-pools . Většinou si vystačíte s použitím čistě async funkcí jen pro socketovou komunikaci a ostatními IO funkcemi volanými v threadpoolu. I rozšiřující "async" knihovny například pro přístup k DB jsou většinou implementovány obalením sync funkcí run_in_executor.
Jo, ale to je strasnej opruz. Odstranuje to tu jedinou potencialni vyhodu async/await - prehlednost kodu. Dalsi problem je, ze v Pythonni implementaci doted chybi zakladni primitiva k tomu, aby to mohl clovek opravdu vyuzivat. Kdyz clovek zna Erlang s jeho linky, monitory, signaly, supervizory, ... tak si v Pythonu pripada, jako by mu nekdo urizl ruku, vytrhl jazyk, zavazal oci a jeste ho jenom tak jakoze ze srandy pichal spendlikama pod nehty...
Další problém je existence několika nekompatibilních základních async knihoven (asyncio, trio, curio). Existuje snaha sjednotit API minimálně mezi trio a asyncio. Dost rozšiřujících knihoven podporuje obojí.
No to je uplnej pruser, kterej jsem ani nezminil, abych se nerozcilil vic nez je nutne
Par let zpatky to byla vylozene tragedie. Dneska nastesti asyncio hodne dobrych featur z ostatnich implementaci pohltilo a jelikoz je ve standardni knihovne, nejspis do budoucna vyhraje. Takze uz to takova traga neni. Nejlepsi je proste imho smirit se s asyncio.
108 Odpovědí
46809 Zhlédnutí