Instead of blocking/non-blocking, blocking with a timeout is probably a better primitive. A simple convenience would be to provide FOREVER (or maybe ONE_MILLEN

Instead of blocking/non-blocking, blocking with a timeout is probably a better primitive. A simple convenience would be to provide FOREVER (or maybe ONE_MILLENNIUM) and ZERO_TIME constants for the maximum (or absurdly large) and zero time duration values. Blocking and non-blocking operations can be implemented as syntactic sugar on top of a timeout (blocking forever and blocking zero <clock_granularity>ies), if you're willing to pay the increased syntactic complexity. In any case, when writing APIs, particularly for back-end code, I prefer to remind the caller to think about "what's the longest I'm willing to wait here?" and force them to be explicit if they're really willing to wait years for a result. Even/especially for async APIs, I prefer to make all of the timeouts explicit. More than one developer has asked me for help with running out of memory that happened to be from queued async thunks due to absurdly slow response from some other back-end service. Depending upon the OS-exposed primitives, perhaps the waiting forever and waiting zero ns might be optimized to use different syscalls as an implementation detail.