digitalmars.D - Swift is getting async, structured concurrency and actors
- Jacob Carlborg (16/16) Dec 11 2020 As the title says, Swift is getting language support for: async/await
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/13) Dec 11 2020 For D it would make a lot of sense to just add C++ style
- Sebastiaan Koppe (3/6) Dec 12 2020 Are they stackless? Then yes.
- Ola Fosheim Grostad (7/13) Dec 13 2020 AFAIK conceptually, but maybe the current backend have to save
- Sebastiaan Koppe (8/15) Dec 13 2020 I just did and from a cursory glance they are. Of course they
- Paulo Pinto (7/23) Dec 13 2020 If you want to bring that into D I advise many of the great talks
- Sebastiaan Koppe (16/24) Dec 31 2020 Thanks, I will take a look.
- IGotD- (4/5) Dec 13 2020 All general purpose CPUs have stacks one way or the other so I'm
- Ola Fosheim Grostad (5/11) Dec 13 2020 By design, RISCish activation frames. Basically a linked list
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (10/22) Jan 04 2021 Hm, tried to look for it now, but didn't find anything on it for
- Sebastiaan Koppe (14/23) Dec 12 2020 I personally think async/await isn't that pretty. I find it very
- Imperatorn (5/20) Dec 31 2020 +1
As the title says, Swift is getting language support for: async/await [1], structured concurrency [2] and actors [3]. The implementation has already started, available in master. Seems like D is more or less the only language without language support for async/await now. But perhaps it's possible to implement only in library code. Kotlin has language support for coroutines, but async/await is implemented in library code. D already has fibers (kind of like coroutines) implemented in library code. [1] https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md [2] https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md [3] https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md -- /Jacob Carlborg
Dec 11 2020
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:As the title says, Swift is getting language support for: async/await [1], structured concurrency [2] and actors [3]. The implementation has already started, available in master. Seems like D is more or less the only language without language support for async/await now. But perhaps it's possible to implement only in library code. Kotlin has language support for coroutines, but async/await is implemented in library code. D already has fibers (kind of like coroutines) implemented in library code.For D it would make a lot of sense to just add C++ style coroutines. LDC/GDC could just look at the C++ implementation and borrow it.
Dec 11 2020
On Friday, 11 December 2020 at 22:12:44 UTC, Ola Fosheim Grøstad wrote:For D it would make a lot of sense to just add C++ style coroutines. LDC/GDC could just look at the C++ implementation and borrow it.Are they stackless? Then yes.
Dec 12 2020
On Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan Koppe wrote:On Friday, 11 December 2020 at 22:12:44 UTC, Ola Fosheim Grøstad wrote:AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked. It should be possible on MIPS, which doesn't use a stack...For D it would make a lot of sense to just add C++ style coroutines. LDC/GDC could just look at the C++ implementation and borrow it.Are they stackless? Then yes.
Dec 13 2020
On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad wrote:On Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan Koppe wrote:I just did and from a cursory glance they are. Of course they need to allocate whenever they suspend from anything but the top-level, but most compilers elide that when it can proof the coroutine doesn't escape the calling function. If we do want coroutines, we should just steal it all, it is pretty great work.Are they stackless? Then yes.AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked.
Dec 13 2020
On Sunday, 13 December 2020 at 15:18:53 UTC, Sebastiaan Koppe wrote:On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad wrote:If you want to bring that into D I advise many of the great talks done by Gor Nishanov, one of the main contributors to the co-routines design, for example “C++ Coroutines: Under the covers" https://www.youtube.com/watch?v=8C8NnE1Dg4AOn Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan Koppe wrote:I just did and from a cursory glance they are. Of course they need to allocate whenever they suspend from anything but the top-level, but most compilers elide that when it can proof the coroutine doesn't escape the calling function. If we do want coroutines, we should just steal it all, it is pretty great work.Are they stackless? Then yes.AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked.
Dec 13 2020
On Sunday, 13 December 2020 at 15:49:47 UTC, Paulo Pinto wrote:On Sunday, 13 December 2020 at 15:18:53 UTC, Sebastiaan KoppeThanks, I will take a look. I recently went down the rabbit hole of some C++ proposals around senders/receivers and cancellation of async tasks. They have some really good ideas. Most of them I am reusing for work. It really all comes together: IO, async, cancellation, nursery, structured concurrency, streams, etc. There are plenty of different approaches in various languages. It would be good to do a thorough review of the landscape and look at how those concepts could be implemented in D, and pick the one that naturally fits the language. D is really lagging in this respect. It has fibers, but they generally use too many resources and aren't portable to platforms like WebAssembly. I really wish I had more time, but I need to finish stuff I started.If we do want coroutines, we should just steal it all, it is pretty great work.If you want to bring that into D I advise many of the great talks done by Gor Nishanov, one of the main contributors to the co-routines design, for example “C++ Coroutines: Under the covers" https://www.youtube.com/watch?v=8C8NnE1Dg4A
Dec 31 2020
On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad wrote:It should be possible on MIPS, which doesn't use a stack...All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
Dec 13 2020
On Sunday, 13 December 2020 at 16:17:32 UTC, IGotD- wrote:On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad wrote:By design, RISCish activation frames. Basically a linked list IIRC. Very common in high level runtimes too. Allows for massive concurrency.It should be possible on MIPS, which doesn't use a stack...All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
Dec 13 2020
On Monday, 14 December 2020 at 01:04:26 UTC, Ola Fosheim Grostad wrote:On Sunday, 13 December 2020 at 16:17:32 UTC, IGotD- wrote:Hm, tried to look for it now, but didn't find anything on it for MIPS. Might have been another architecture, but probably not worth it with caches that came in the 90s and then 64-bit. Anyway, the basic idea is that you don't require a contiguous stack, so that you can have many threads without running into address space problems. So, useful for simulations, but also for the ability to detach a computation from one thread and sending it to another one.On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad wrote:By design, RISCish activation frames. Basically a linked list IIRC. Very common in high level runtimes too. Allows for massive concurrency.It should be possible on MIPS, which doesn't use a stack...All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
Jan 04 2021
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:As the title says, Swift is getting language support for: async/await [1], structured concurrency [2] and actors [3]. The implementation has already started, available in master.I personally think async/await isn't that pretty. I find it very infectious. Before long your whole program has async/await everywhere. If you think about it, async/await, concurrency and coroutines wouldn't exist if it wasn't for IO and our desire to do useful work when a piece of code is waiting on it. Async IO is one way to fix it, but that generally leads to callback hell, and hence to async/await. Vibe.d and photon are two approaches that fix it without callback hell, and thus without async/await. Vibe.d has its warts and photon is mostly DOA, but they do show a promising alternative.Seems like D is more or less the only language without language support for async/await now. But perhaps it's possible to implement only in library code. Kotlin has language support for coroutines, but async/await is implemented in library code. D already has fibers (kind of like coroutines) implemented in library code.It mostly is, but it needs to integrate with the GC as well.
Dec 12 2020
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:As the title says, Swift is getting language support for: async/await [1], structured concurrency [2] and actors [3]. The implementation has already started, available in master. Seems like D is more or less the only language without language support for async/await now. But perhaps it's possible to implement only in library code. Kotlin has language support for coroutines, but async/await is implemented in library code. D already has fibers (kind of like coroutines) implemented in library code. [1] https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md [2] https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md [3] https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md+1 D. Today we have efforts which have stopped because async/await was missing 😢
Dec 31 2020