5 ms·

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 -

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 6y ago
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 6y ago
  Why not? The fix there sounds like it's as simple as adding some yield points.
  - ori_b 6y ago
    Yield points in the middle of a large matrix multiplication (for example)? Manually scheduling threads seems like a really shitty way to program
    - cycloptic 6y ago
      Not really? That's cooperative multitasking and it's used a lot: https://en.wikipedia.org/wiki/Cooperative_multitasking 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 6y ago
        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 6y ago
        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.
        deleted 6y ago
        [deleted]
        ori_b 6y ago
        Those languages are also well known for not handling multiple cpu bound threads well. (And for that matter, it's simply wrong about Python, which uses native threads, but locks very heavily: you need to write native code to use more than one core effectively from one process.) The goal is to NOT do what you're suggesting. It's a holdover from when native threads were much more expensive than they are today, and multiple cores on a single cpu were rare.

ori_b 6y ago

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 6y ago
Why not? The fix there sounds like it's as simple as adding some yield points.
- ori_b 6y ago
  Yield points in the middle of a large matrix multiplication (for example)? Manually scheduling threads seems like a really shitty way to program
  - cycloptic 6y ago
    Not really? That's cooperative multitasking and it's used a lot: https://en.wikipedia.org/wiki/Cooperative_multitasking 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 6y ago
      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 6y ago
        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.
        deleted 6y ago
        [deleted]
        ori_b 6y ago
        Those languages are also well known for not handling multiple cpu bound threads well. (And for that matter, it's simply wrong about Python, which uses native threads, but locks very heavily: you need to write native code to use more than one core effectively from one process.) The goal is to NOT do what you're suggesting. It's a holdover from when native threads were much more expensive than they are today, and multiple cores on a single cpu were rare.