3 ms·

This is not gonna end well: https://tclementdev.com/posts/what_went_wrong_with_the_libdispatch.html https://tclementdev.com/posts/what_went_wrong_with_the_libdi

• bsaul 6y ago
  No idea why you got downvoted. The fact that the first implementation of the actor system is most certainly going to be on top of libdispatch makes it a very interesting property. Libdispatch is really not known for being able to spawn thousands of "light thread". And so there is indeed a potential pitfall in making asynchronous + concurrent code easier. However, after having read a lot of the swift proposal relative to concurrency, i am still unsure if the end result of production code is going to be lots of actors running in parallel, or just lots of async calls multiplexed on a few OS threads.
  • astrange 6y ago
    You can easily have thousands of tasks (blocks) in dispatch, and thousands of queues as long as they're targeted to the same base queue. The issue with dispatch is that it wasn't communicated enough that you want to have a few base queues and then a tree of other serial queues on top of that, so people end up running too many CPU threads at once, on a device that often has less than one core free at a time.
• astrange 6y ago
  This post is a somewhat inaccurate rewording of official advice from the dispatch team at Apple, but that's one of the teams working on Swift concurrency so, like, it'll be fine.
• viktorcode 6y ago
  lidbdispatch is a concrete implementation of a scheduler on OS threads. Actors (and new async model in Swift) are abstractions that are independent of underlying concurrency implementation. So the presumption that the new asynchronous model will inescapable have threads overhead is wrong.