Máš na mysli paralelní polling, něco jako https://docs.rs/futures/0.3.1/futures/macro.join.html ? Nebo něco komplikovanějšího? V téhle problematice nemám zkušenosti.
Napadají mě minimálně dva rozdílné způsoby, jak by se to dalo implementovat:
1. Promisy běží (potenciálně) skutečně paralelně, každý (potenciálně) na svém jádře
2. Promisy jsou odstartované "zaráz" (rychle po sobě), ale paralelně běží jenom operace "mimo jazyk" (typicky IO)
To první je asi jasný. To druhý je jenom "jakože paralelní" v JS stylu. Od serializovaných awaitů by se to poznalo tak, že
await sleep(1)
await sleep(1)
await sleep(1)
by netrvalo ~ tři sekundy, ale ~ jednu.
To druhé v JS jde implementovat, ale musí se to (AFAIK) udělat ručně přes Promise.all()
V tom je ten vtip - Rust není magický jazyk, nedělá žádné legrácky typu GC a automatickou paralelizaci. Programátor v Rustu by vždycky měl rozumět tomu, co dělá, když překročí hranice, kompilátor ho pošle k šípku a pak se dotyčný musí zamyslet a konflikt představ vyřešit. Třeba si vem takový Rayon - na první pohled to vypadá jako velká magie, která vyřeší něco za Tebe, on skutečně leccos umí díky možnostem, které Rust a jeho typový systém umožňuje, jenže pak zjistíš, že pro paralelní iterátor buďto musíš použít nějakou kolekci, kterou Rayon podporuje nebo si budeš muset naimplementovat příslušný trait nebo se na to (jako já, když jsem si s tím hrál) vykašleš úplně a prostě si uděláš vlastní paralelní iterátor, který si synchronizaci řeší sám. To není moc těžké, ale musíš u toho přemýšlet a narazíš pak (jako já) třeba na to, že objekt má delší životnost, než ses domníval a najednou se výpočet provádí de facto sekvenčně.
Proto bych osobně neočekával, že tohle Rust kdy bude dělat sám - můžeš mít simultánní polling, ale ty přesahy mezi vlákny si řešíš sám v nižší vrstvě. Nebo tam holt budeš mít nějaký objekt, který to bude umět řešit elegantně za Tebe oboje, ale zase budeš muset splnit nějaké podmínky na obou koncích - v té paralelní metodě pro multithread a v tom "klientu" v původním vláknu.