zlacker

There's no concurrency issues with async programming.

No race conditions, no inter thread coordination, no concerns about all the weird shit that happens when doing multi threading.

>>andrew+(OP)
One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have. So you will still have all the concurrency issues with async in that case.

Only if you limited async to only one thread on one core (why would you do that?) you could avoid that.

>>dannym+5e
>> One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have

Errrr..... no it's not. Your statement is flat out wrong. async is single threaded.

You're not really understanding async.

async is single threaded. If you want to maximise your cores then run multiple instances of a single threaded process using systemd or something, or use your application to launch multiple async threads.

You can, in python and probably in Rust, run an executor, which essentially is running a synchronous process in a thread to make some bit of synchronous work compatible with async, but that's not really ideal and it's certainly not the purpose of async.

>>andrew+Bk
`async` is neither multi-threaded nor single-threaded by default. It all depends on the underlying runtime.

Rust's Tokio runtime, for example, is multi-threaded by default and makes progress on several tasks at the same time by using multiple threads.

>>andrew+(OP)
A common belief but not quite true. You can have race conditions and weird shit happening in async systems.

The usual way it happens is that you write some code inside an async function that's straight line not suspending, and then later someone adds an await inside it. The await returns to the event loop, at which point an event arrive that you didn't expect. You now have control flow jumping to somewhere else completely, possibly changing state in a way that you didn't anticipate. When the original function resumes it sees something change concurrently.

>>andrew+Bk
I replied to you in order to help you. I'm doing async since 2007.

I use async regularily for my clients, and I'm 100% sure that the usual async executors in Rust are multithreaded. I just ran gdb on an async program again, and, sure enough, the tokio async executor has 16 threads currently (that's just on a laptop with 16 cores).

    async fn say_world() {
        println!("world");
    }

    #[tokio::main]
    async fn main() {
        loop {
            say_world().await;
        }
    }

    (gdb) info threads
      Id   Target Id                 Frame 
      1    LWP 32716 "r1"            0x00007fdc401ab08d in ?? ()
      2    LWP 329 "tokio-runtime-w" 0x00007fdc401ab08d in ?? ()
      3    LWP 330 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      4    LWP 331 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      5    LWP 332 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      6    LWP 333 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      7    LWP 334 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      8    LWP 335 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
      9    LWP 336 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     10   LWP 337 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     11   LWP 338 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     12   LWP 339 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     13   LWP 340 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     14   LWP 342 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     15   LWP 343 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     16   LWP 344 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()
     17   LWP 345 "tokio-runtime-w" 0x00007fdc401a8482 in ?? ()

Just try it out.

Also, think about it. Using async in order to speed up I/O and then pin the async executor to just one core of your 200 cores on a server is not exactly a winning strategy.

>executor, which essentially is running a synchronous process in a thread to make some bit of synchronous work compatible with async

That's not what an executor is.

Also, the thing above is an example of parallelism, so even worse than concurrency. But even with an one-thread-async-executor you could still get concurrency problems with async.

>If you want to maximise your cores then run multiple instances of a single threaded process using systemd or something, or use your application to launch multiple async threads.

It is not 1995. Your idea would make scheduling even harder than it already was, and it would add massive memory overhead. If you are gonna do that, most of the time, just use synchronous processes to begin with--no need for async.