Comment by masklinn

Comment by masklinn 2 days ago

2 replies

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 a day ago

> 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 a day ago

    > 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.