Local async executors and why they should be the default

Post by insanitybit » Wed, Jul 19, 2023, 3:42 PM UTC

bombela wrote: post #180

insanitybit wrote: post #162

Earlier quoted context omitted.

> The supervisory system is an extra, you don't technically need it but it can help make your application bullet proof and I would definitely recommend if you go the Erlang route to use it to your advantage. An actor system without supervisors is throwing away a lot. How do you handle an actor that crashes? The thing is, again, Actors are very low level - they're a foundational model. You end up having to build proto…

I am responding to the very last point about dropping a future and the resource usage. Let's assume a future that implements reading from a network socket. And the file descriptor (fd) was already passed to epoll/select (I am ignoring io_uring). After dropping the future, the socket is is still being considered by the kernel for reading. Eventually epoll will return, and the IO runtime (like tokio) will notice the st…

Post by pjmlp » Wed, Jul 19, 2023, 3:44 PM UTC

tjoff wrote: post #177

pjmlp wrote: post #175

Earlier quoted context omitted.

Great that D, Go, Swift, C#, Nim, Eiffel, Common Lisp, Haskell, OCaml,.... also offer ways of doing it.

You don't seem to care but you are missing the point.

Post by tjoff » Wed, Jul 19, 2023, 3:48 PM UTC

pjmlp wrote: post #184

tjoff wrote: post #182

Earlier quoted context omitted.

The promise with a good architecture is that the doom part is more infrequent though. And that when the Go/Java doom scenario bites you you'll have a whole lot of technical debt to pay back.

There are more languages to chose from with automatic memory management than Go and Java. Chose the one that provides the right set of tools for high performance code.

Post by duped » Wed, Jul 19, 2023, 3:57 PM UTC

datadeft wrote: post #166

duped wrote: post #76

Earlier quoted context omitted.

I'm confused what you mean here. If you have a function that "depends on" another function you call it within the other function. If it's async you .await it. Do you mean something about spawning tasks or passing callbacks around?

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…

   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(), config),
        create_table_summaries_cache(aws_clients.clone(), config),
        create_job_summaries_cache(aws_clients.clone(), config),
        create_query_summaries_cache(aws_clients.clone(), config),
    )?;

Post by almindor » Wed, Jul 19, 2023, 4:05 PM UTC

borrow wrote: post #52

sanxiyn wrote: post #38

Earlier quoted context omitted.

Eh, in that case, you can also just write single or multithreaded Rust code, entirely ignoring async Rust. I do. And multithreaded Rust is much more pleasant experience than multithreaded C++. Which dependency is forcing async Rust on you? Alternatives are usually available.

Postgres (which is a wrapper around tokio-postgres, and as a result drags the whole tokio bloated dependency graph). I would love to have a purely sync alternative to that.