> In my view it's an exaggeration to call functions that might block for a long time "not async safe". "Not async safe" is a loaded term here that means "not c

> In my view it's an exaggeration to call functions that might block for a long time "not async safe". "Not async safe" is a loaded term here that means "not complying with requirements of being a good citizen in the entire forest of async workers". As another poster said: it's expected most workers to return in 0.1 - 1.0 ms. After that the guarantees of async start to fall apart. It's the same with Erlang's BEAM btw: it has an amazing scheduling primitives and you can literally spawn 50k green threads and you'd barely see a blip of lag anywhere BUT that's because the scheduler is preemptive and aggressively switches off a worker if it hasn't yielded in a while (this is not 100% the truth, I am simplifying it here). But if you start calling native functions that don't respond in 1ms or less, the scheduler is starting to struggle and you do start seeing lags that you normally never would. So yeah, "not async safe" here means more or less "not being a good citizen". No abstraction is free. Until we have something like the BEAM on a hardware level and anything and everything is preempted without you ever having a say on it, then such async runtime if-s and but-s will keep existing. It's a fundamental limitation of our hardware and OS-es.