You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm studying Rust and Tokio framework currently, and it's naturally for people to compare Rust async with Golang Goroutine.
Goal
Verify my understanding for Rust Async and Tokio
Comprehensive on Tokio mechanism
Basic Ideas
Tokio/Rust Async
Rust creatively decouples compile time and runtime. Means that it only provides compile implementation, which, properly (I'm not sure as I don't investigate on Rust's compilation yet) wraps async fun into some sort of task structures, as well as wraps up .await into some checks on poll status and call some sort of schedule() implementation due to the poll result.(just like a OS do for a thread)
More over, rust defers runtime implementation to developers, which, developers could either develop the async impl themselves, or leverage frameworks like Tokio. .await is some kind of a SafePoint for Tokio, just like a safepoint for JVM GC, where, Tokio is able to do a re-schedulation (please correct me if I was wrong). What's important, calling a standard lib that blocks task (like std:xxx::sleep)inside the async func, will cause a huge damage on Tokio as it will block other async tasks' execution, which is unacceptable for online realtime traffic, instead of calling the std directly, Tokio has provided its own standard lib as tokio::xxx::sleep()
Golang
Golang dominates both Compile as well as Runtime for Goroutine, including standard lib, calling a xxx.sleep won't harm other Goroutines.
But it also has other problems and troubles. Like, in some circumstance, when goroutine is blocked by device IO, golang runtime will create more OS threads to support for the other goroutines to schedule (based on GPM model in Golang).
Comparasion
Rust Async & Tokio
Golang & Goroutine
Implementation
Compile and Runtime decouple
Compile And Runtime couple
Runtime
Runtime is independent impled by frameworks like Tokio
Runtime is supported by Golang
Standard Lib
Standard lib not completely support for async
Standard lib supports for goroutine with detail consideration
Trouble time
Calling block method inside an async func
calling long blocking device IO through hundreds/thousands Goroutines
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Context
Background
I'm studying Rust and Tokio framework currently, and it's naturally for people to compare Rust async with Golang Goroutine.
Goal
Basic Ideas
Tokio/Rust Async
Rust creatively decouples compile time and runtime. Means that it only provides compile implementation, which, properly (I'm not sure as I don't investigate on Rust's compilation yet) wraps
async fun
into some sort of task structures, as well as wraps up.await
into some checks onpoll
status and call some sort ofschedule()
implementation due to thepoll result
.(just like a OS do for a thread)More over, rust defers runtime implementation to developers, which, developers could either develop the async impl themselves, or leverage frameworks like
Tokio
..await
is some kind of aSafePoint
for Tokio, just like asafepoint
for JVM GC, where, Tokio is able to do a re-schedulation (please correct me if I was wrong).What's important, calling a standard lib that blocks task (like
std:xxx::sleep
)inside theasync func
, will cause a huge damage on Tokio as it will block other async tasks' execution, which is unacceptable for online realtime traffic, instead of calling the std directly, Tokio has provided its own standard lib astokio::xxx::sleep()
Golang
Golang dominates both
Compile
as well asRuntime
forGoroutine
, including standard lib, calling axxx.sleep
won't harm other Goroutines.But it also has other problems and troubles. Like, in some circumstance, when goroutine is blocked by device IO, golang runtime will create more OS threads to support for the other goroutines to schedule (based on GPM model in Golang).
Comparasion
async func
Beta Was this translation helpful? Give feedback.
All reactions