3 ms·

I reimplemented async, except that the event loop is only invoked explicitly and under the programmer's control. I know it doesn't sound like a lot, but it is.

hot_gril 3y ago
Is the idea that you might be fanning out and want to delay starting the event loop? Fanning out in JS looks like: const fn = async (arg) => { ... }; // calls some RPC const results = await Promise.all(args.map(fn)) which might technically be starting the first func before the second is in the event loop, but I don't see why that matters for what I'm doing.
- gavinhoward 3y ago
  It does matter for what I'm doing.
  - hot_gril 3y ago
    You said most use cases, so I was thinking of a typical backend that's handling requests, calling RPCs, doing DB queries, etc.
- saghm 3y ago
  In Rust (which is the async/await system mentioned in the article), futures don't start until they're polled, so doing the pattern you describe wouldn't even have the ordering part you mention (unless you wanted it to, in which case you could use something like Tokio's `spawn`).
pitaj 3y ago
async event loops in Rust are invoked explicitly by the programmer as well.
- gavinhoward 3y ago
  Are they always invoked explicitly? Or is it sometimes implicit?
  - pitaj 3y ago
    The closest to implicit you can get is the `#[tokio::main]` attribute macro [1], which expands to something like this fn main() { tokio::runtime::Builder::new_multi_thread() .enable_all() .build() .unwrap() .block_on(async { println!("Hello world"); }) } [1]: https://docs.rs/tokio/latest/tokio/attr.main.html#using-the-multi-thread-runtime https://docs.rs/tokio/latest/tokio/attr.main.html#using-the-...
  - saghm 3y ago
    That's technically something the runtime implementation can choose, but for Tokio, the most common runtime, the sibling comment is correct that the only way to avoid having to explicitly define it is to use an annotation on the main function (which just generates the call to instantiate the runtime via a macro).
  - saghm 3y ago
    That's technically something the runtime implementation can choose, but for the most common runtime, Tokio,

hot_gril 3y ago

Is the idea that you might be fanning out and want to delay starting the event loop? Fanning out in JS looks like: const fn = async (arg) => { ... }; // calls some RPC const results = await Promise.all(args.map(fn)) which might technically be starting the first func before the second is in the event loop, but I don't see why that matters for what I'm doing.

gavinhoward 3y ago
It does matter for what I'm doing.
- hot_gril 3y ago
  You said most use cases, so I was thinking of a typical backend that's handling requests, calling RPCs, doing DB queries, etc.
saghm 3y ago
In Rust (which is the async/await system mentioned in the article), futures don't start until they're polled, so doing the pattern you describe wouldn't even have the ordering part you mention (unless you wanted it to, in which case you could use something like Tokio's `spawn`).

pitaj 3y ago

async event loops in Rust are invoked explicitly by the programmer as well.

gavinhoward 3y ago
Are they always invoked explicitly? Or is it sometimes implicit?
- pitaj 3y ago
  The closest to implicit you can get is the `#[tokio::main]` attribute macro [1], which expands to something like this fn main() { tokio::runtime::Builder::new_multi_thread() .enable_all() .build() .unwrap() .block_on(async { println!("Hello world"); }) } [1]: https://docs.rs/tokio/latest/tokio/attr.main.html#using-the-multi-thread-runtime https://docs.rs/tokio/latest/tokio/attr.main.html#using-the-...
- saghm 3y ago
  That's technically something the runtime implementation can choose, but for Tokio, the most common runtime, the sibling comment is correct that the only way to avoid having to explicitly define it is to use an annotation on the main function (which just generates the call to instantiate the runtime via a macro).
- saghm 3y ago
  That's technically something the runtime implementation can choose, but for the most common runtime, Tokio,