In my experience with .net, async/await introduce a non-obvious multithreading model, which remaining hidden under the hood, can still inflict concurrency issues on your code: race conditions and deadlocks. And while C++ and C# don't know about shared types, D will need to catch concurrent access to data, as it's required by D type system.

On Tuesday, 28 October 2014 at 12:30:22 UTC, Kagamin wrote:
> In my experience with .net, async/await introduce a non-obvious multithreading model, which remaining hidden under the hood, can still inflict concurrency issues on your code: race conditions and deadlocks. And while C++ and C# don't know about shared types, D will need to catch concurrent access to data, as it's required by D type system.

This is why one of the biggest improvements in Visual Studio 2013 is async/await debugging.

Visual Studio 2014 has a few more improvements, if I am not mistaken.

I think, it's for seamless debugging. The debugger support for async/await is indeed non-trivial, because code is mutated by the compiler a lot, but I don't think it has anything to do with concurrency. Official MS position is async/await has no concurrency problems.

On 10/28/14 8:25 AM, Kagamin wrote:
> I think, it's for seamless debugging. The debugger support for
> async/await is indeed non-trivial, because code is mutated by the
> compiler a lot, but I don't think it has anything to do with
> concurrency. Official MS position is async/await has no concurrency
> problems.

Yah, my understanding of async/await is it's all single-threaded. -- Andrei

It's usually single-threaded by default, but this is achieved by routing continuation to the original thread through its synchronization context, while in multithreaded mode continuation can be executed in thread pool on any thread.

Just out of curiosity, is anyone planning to implement this?

As for why it's not already implemented, is it because of lack of interest, or prohibitive reasons?



On Friday, 24 October 2014 at 10:33:40 UTC, Martin Nowak wrote:
> This is so much better than Fibers.
> http://youtu.be/KUhSjfSbINE
>
> What I like most about the proposal is that you can adapt await by specializing template functions, similar to how range based foreach works.
> It also isn't tied to a particular scheduling mechanism and of course consumes much less memory than stack based suspension.

On Friday, 20 February 2015 at 17:51:17 UTC, bitwise wrote:
> Just out of curiosity, is anyone planning to implement this?
>
> As for why it's not already implemented, is it because of lack of interest, or prohibitive reasons?
>
>
>
> On Friday, 24 October 2014 at 10:33:40 UTC, Martin Nowak wrote:
>> This is so much better than Fibers.
>> http://youtu.be/KUhSjfSbINE
>>
>> What I like most about the proposal is that you can adapt await by specializing template functions, similar to how range based foreach works.
>> It also isn't tied to a particular scheduling mechanism and of course consumes much less memory than stack based suspension.

They are waiting for your pull request :o)

> They are waiting for your pull request :o)

Welll... I would like to try, but there is good reason behind the noncommital phrasing of my question :)

I experimented with stackful coroutines in C++, but I think stackless resumable functions will be more difficult. I assume I can harvest most of what I need from other parts of D.

My initial thoughts on this is that I could have resumable functions return a special range which contained 3 things:
-a pointer to the function
-all the stack variables from the function
-an integer index into a jump table at the beginning of the resumable function

At compile time, each usage of yield in the resumable function would be replace with:
-a command to update the jump table index, followed by
-a label, who's offset would be contained in the jump table

So initially calling a resumable function would return the range in question which would repeatedly call into the resumable function with a different index until the end of the resumable function was reached.

Input on this would be appreciated.

On Sat, 21 Feb 2015 21:19:32 +0000, bitwise wrote:

> Input on this would be appreciated.

it seems to me that you can "abuse" delegates for this (i mean the underlying "fat pointer"). resumable function can create closure (i think all the code for this is already here), "resume address" pointer (this can be added to closure), pointer to "real" delegate, hidden "yield point" address, and return a delegate which does something like this on call:

* executes "real" delegate from "resume address".
* "real" delegate yields by doing indirect call to "resume address"
* assembler code at "resume address" stores new resume address (it's on
stack now)
* and returns from "wrapping delegate"

so from the point of programmer this will look as an ordinary delegate, even with the same type, and it will be usable anywhere where ordinary delegate is usable.

On Sat, 21 Feb 2015 21:19:32 +0000, bitwise wrote:

p.s. i think you will need to so some housekeeping in "wrapping delegate", of course. it depends of compiler internals though, and from codegen details.