<div dir="ltr">> <span style="font-size:12.800000190734863px">Yes, I'm aware of that but that can change any day and there might already be cases where it doesn't work. Don't get me wrong, I personally like this programming model but we won't be able to pitch this to swift-evo as it's currently officially UB as Joe confirms.</span><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I know. I was just saying thank thankfully we didn't have issues with that so far. I'm waiting for concurrency model discussions on swift-evo so I can pitch for coroutines in the language level. This is a bit off-topic, but I really think coroutines should be the way to go on the server side. For UI applications you need preemptive scheduling because the UI thread needs to be running all the time, but for server apps you don't have UI, so you don't need preemptive behaviour. Threads are much slower than coroutines and they also require asynchronous APIs which are plain harder to work with than synchronous APIs. There's also the issues with race conditions, etc. Even though the API for UI apps will always need threads.. and async/await is definitely the way to go for them, imo. For the server side we can do much better. Better in performance terms and usability terms. Async APIs aren't intuitive and most programmers don't know how to use them properly. So although this issue is a bit off-topic now. When the time comes we can't run away from this. </span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">></span><span style="font-size:12.800000190734863px"> </span><span style="font-size:12.800000190734863px">So whatever the Swift concurrency model will look like, I'm sure there's be a transition path. Also: The Swift concurrency model won't just appear, at some point that'll be discussed on swift-{evo,dev} and you're more than welcome to pitch in!</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">This makes me think that maybe the work we're doing here might be time not wisely spent exactly because of that. Maybe it makes more sense to really get this project going when we have a concurrency model well defined since this is a vital part of server-side.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 May 2017 at 12:05, Johannes Weiss <span dir="ltr"><<a href="mailto:johannesweiss@apple.com" target="_blank">johannesweiss@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Paulo,<br>
<span class=""><br>
> On 30 May 2017, at 4:00 pm, Paulo Faria <<a href="mailto:paulo@zewo.io">paulo@zewo.io</a>> wrote:<br>
><br>
> Regarding that. I'm fine with not providing synchronous APIs, right now. As long as we design the APIs in a way that adding those later becomes natural. (I *really* *really* hope we get support for coroutines in Swift 5). That's my only concern.<br>
<br>
</span>so do I. But see it this way: Foundation and the whole ecosystem is _full_ of APIs that take async continuation blocks/closures. So whatever the Swift concurrency model will look like, I'm sure there's be a transition path. Also: The Swift concurrency model won't just appear, at some point that'll be discussed on swift-{evo,dev} and you're more than welcome to pitch in!<br>
<span class=""><br>
<br>
> About the undefined behaviour regarding setjmp/longjmp. Interestingly, I've been using libmill/libdill (provides coroutines with context switching using assembly instead of setjmp/longjmp) with Zewo for the past 2 years. And we never once had a problem with that.<br>
<br>
</span>Yes, I'm aware of that but that can change any day and there might already be cases where it doesn't work. Don't get me wrong, I personally like this programming model but we won't be able to pitch this to swift-evo as it's currently officially UB as Joe confirms.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Johannes<br>
<br>
<br>
</font></span></blockquote></div><br></div>