[masklinn]

It’s more like adding a runtime handle to the struct.

Modulo that I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations. So a library can’t take a runtime for a caller and get whatever implementation the caller decided to use.

[dwattttt]

> I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations.

You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.

I've implemented Future (Rust) on a struct for a Windows operation based only on C calls into the OS. The struct maintains everything needed to know the state of the IO, and while I coupled the impl to the runtime for efficiency (I've written it too), it's not strictly necessary from memory.

[masklinn]

> You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.

While C doesn't have async OS generally provide APIs which are non-blocking, and that is what async runtimes are implemented on top of.

By sync operations I mean implementing an "async" runtime entirely atop blocking operations, without bouncing them through any sort of worker threads or anything.

[dwattttt]

I've been pondering this, it feels like a brain teaser. Is it possible to create an "async" runtime out of only blocking operations?

It feels like it turns purely on what "blocking operations" are (does setting a lock bit and returning count as non-blocking?)