On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote:
> On 2017-07-10 15:37, Gerald wrote:
>
>> Having said that, I'm in the camp where this doesn't make much sense. Using fibers on the main UI thread is likely going to result in a blocked UI whenever a fiber takes too long to do its work. History has shown that cooperative multi-tasking typically doesn't work well for UI applications.
>
> It's that basically the whole idea of async/await? Seems like Microsoft is pushing quite heavily for that in GUI code.

Thanks for the link, I'm not active with .Net so I had to go look it up. Reminds me a lot of the way node.js works. If all your async activity is IO bound maybe it works fine and I'm wrong about this.


My past experience has been that it's challenging to determine the appropriate times to yield particularly with a lot of async activity happening. However with it baked into the framework and a simplified API maybe it becomes less of an issue.

I'll have to do more reading on it, again thanks for the pointer.

On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote:
> On 2017-07-09 23:12, bauss wrote:
>
>> I believe OSX (possibly macOS too.) only allows it from the main thread.
>
> Yes, that's correct. But what's the difference between OSX and macOS ;)

Well besides that it's newer versions of the OS, then nothing much I guess. It could potentially change such specs though.

On 2017-07-11 04:40, Gerald wrote:

> Thanks for the link, I'm not active with .Net so I had to go look it up. Reminds me a lot of the way node.js works. If all your async activity is IO bound maybe it works fine and I'm wrong about this.
> 
> 
> My past experience has been that it's challenging to determine the appropriate times to yield particularly with a lot of async activity happening. However with it baked into the framework and a simplified API maybe it becomes less of an issue.
> 
> I'll have to do more reading on it, again thanks for the pointer.

I'm not that familiar with .Net either but this async/await feature is spreading across languages: C++, JavaScript, .Net, Dart and possibly others.

As far as I understand it consists of two parts: coroutines (resumable functions) and asynchronous operations, usually IO. Any async function returns some form of future type. If you call that function, it will return immediately and let the execution continue. Now it's possible to do work that is independent of the result of the previous call. When you do need the result of the first call, you call "await" on the return value of that call, the future. If the result is ready, everything is fine and the execution continues. If the result is not ready, your function will suspend and the caller will continue the execution.

You don't need to do any explicit yielding due to the language and framework support. The only thing you need to determine is when you need the result of an aysnc function call.

-- 
/Jacob Carlborg