[cycloptic]

That doesn't seem to be related to async? I don't know the details of rust's async implementation but that sounds like a problem with your application's setup -- you should be able to have a single threaded async executor that uses an event loop, or in simple cases, just calls poll/select directly?

To put it another way, it's unfortunate that particular synchronous API is implemented using threads, but there is nothing about async that implies one way or another that a synchronous method will be implemented using threads -- I've seen plenty of (questionable) C functions that do similar things like using pthread_create and then pthread_join immediately after to fake a blocking task.

[ori_b]

Er? No, the point is that threads are what you want for cpu-bound tasks. Async does not deal well with long running cpu intensive jobs that hog the cpu without yield points.

[cycloptic]

Why not? The fix there sounds like it's as simple as adding some yield points.

[ori_b]

Yield points in the middle of a large matrix multiplication (for example)?

Manually scheduling threads seems like a really shitty way to program

[cycloptic]

Not really? That's cooperative multitasking and it's used a lot: https://en.wikipedia.org/wiki/Cooperative_multitasking

But regardless, the GP post was not taking about matrix math, it seems it was talking about sending an HTTP request and waiting for a response, which is something that actually is I/O bound on the TCP socket.

[ori_b]

I know what it is, and there's a reason that all the systems listed as using it are obsolete.

> "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy."

Strongly implies to me that there's a CPU-bound component there.

[cycloptic]

The systems that use it as a native threading model are obsolete, but there's also this sentence there:

>Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python.

There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread for an HTTP request to return, that's never going to be CPU-bound. I still am failing to see what the problem here is besides a complaint about some rust crate only supporting a multi-threaded executor, which again is a different problem than whether it's done with async futures or not. One could just as easily write some C code that forces the use of threads.