Local async executors and why they should be the default

Post by pdimitar » Wed, Jul 19, 2023, 6:43 PM UTC

insanitybit wrote: post #238

pdimitar wrote: post #226

Earlier quoted context omitted.

> but I'm just not seeing a fundamental problem. Well, I mentioned it a few times in this thread: things are mixed in non-intuitive ways -- async/await, tokio, and various crates (including StreamExt which was not at all obvious and it took me a while to finally find mentioned in a few blog posts and GitHub gists). It just introduces friction and nowadays I am more averse to tech that requires more homework. Admitted…

> Would you write it differently and if so, how? It's really hard to say because I don't fully know your use case. Maybe your way was the right way but I think I probably would have done something differently. Maybe a priority queue of jobs with a static pool of workers.

Post by datadeft » Wed, Jul 19, 2023, 6:46 PM UTC

duped wrote: post #187

datadeft wrote: post #166

Earlier quoted context omitted.

I have this function that I still struggle to write. async fn function_handler(_event: Request) -> Result , Error> { let aws_clients = AwsClients { s3_client: S3_CLIENT.get().await.to_owned(), glue_client: GLUE_CLIENT.get().await.to_owned(), athena_client: ATHENA_CLIENT.get().await.to_owned(), }; println!("{}", aws_clients); let config = CONFIG.get().await; let version = VERSION.get().await; let db_eid_cache = create…

If you want to .await multiple futures that can return an error you can use tokio::try_join, futures_utils::try_join_all, etc. For example: let ( db_eid_cache, table_eid_cache, job_eid_cache, table_summaries_cache, job_summaries_cache, query_summaries_cache, ) = try_join!( create_db_eid_cache(aws_clients.clone(), config), create_table_eid_cache(aws_clients.clone(), config), create_job_eid_cache(aws_clients.clone(), c…

Post by insanitybit » Wed, Jul 19, 2023, 6:48 PM UTC

bombela wrote: post #195

insanitybit wrote: post #181

Earlier quoted context omitted.

I'm not sure how an actor would solve that problem. You're describing the way a system call works, which is not relevant to how your userland asynchrony works. In either case you're always "leaking" (I'd say "holding") the resource while you wait for the kernel to give it back to you.

Indeed I was merely describing how it behaves within the context of future + ioloop with tokio. I didn't take a stance on future vs actor. In Rust my instinct tells me the difference between actor and future is negligible. Because it compiles down to almost the same thing. But I wouldn't bet my life on it. Note that my understanding of what an actor is might be wrong. I assume an actor is a sort of thread with a main…

Post by mgaunard » Wed, Jul 19, 2023, 6:50 PM UTC

samsquire wrote: post #107

mgaunard wrote: post #3

Multithreading, why does everyone always do it wrong? One of life's big questions.

CPU cycles are practically free but memory latency and synchronization are not. (Hardware threads gives more CPU cycles capacity). People's scalability problems are memory related, not CPU cycles. In other words, we can't scale updating a single memory location with more hardware threads. People often want to scale the updating of something so they add threads, but the contention of memory synchronization prevents th…

Post by insanitybit » Wed, Jul 19, 2023, 6:56 PM UTC

pdimitar wrote: post #246

insanitybit wrote: post #239

Earlier quoted context omitted.

I don't think there's a meaningful difference between an Erlang actor and an operating system process other than the upfront memory allocation size. The salient different to me is the supervisory structures. In Erlang you must compose them, in operating systems the kernel does that for you, or you move the responsibility into a distributed queue, etc. As for scale, I don't really know how to reconcile "I'm fine just…

> in operating systems the kernel does that for you Does it really? I am not an uber Linux expert but I have only heard of systemd doing that. Serious question, I'll appreciate more examples. > As for scale, I don't really know how to reconcile "I'm fine just paying another 20 dollars" with "I'm worried about how my kernel will schedule my processes". Sorry if I was unclear, I meant it as "I don't want to worry if th…