<div dir="auto">> <span style="font-family:sans-serif">Please apologise for the nitpicking but I thought now introducing a third axis (scheduling) might lead to more confusion.</span><br style="font-family:sans-serif"><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Haha, you actually introduced a fourth axis. And thank you for that. It enlightened my view of the subject.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">sync/async API</div><div class="gmail_extra" dir="auto">blocking/non-blocking IO</div><div class="gmail_extra" dir="auto">preemptive/cooperative Scheduling</div><div class="gmail_extra" dir="auto">kernel-space/user-space Context switching</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">And it shouldn't be confusing. People should know these concepts are all distinct.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">People shouldn't blindly say async is better than sync when they actually mean non-blocking async is better than blocking sync. I can agree with that a 100%. But if you ask me:</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">user-space cooperative context switching with non-blocking synchronous APIs vs kernel-space preemptive context switching with non-blocking asynchronous APIs</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">I'll say *<span style="font-family:sans-serif">user-space cooperative context switching with non-blocking synchronous APIs*</span><span style="font-family:sans-serif"> </span>any time of day, haha.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote" dir="auto">On May 30, 2017 14:38, "Johannes Weiss" <<a href="mailto:johannesweiss@apple.com">johannesweiss@apple.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br>
> On 30 May 2017, at 5:44 pm, Paulo Faria <<a href="mailto:paulo@zewo.io">paulo@zewo.io</a>> wrote:<br>
><br>
> Yeah, it's important to distinguish:<br>
><br>
> sync/async APIs<br>
> blocking/nonblocking IO<br>
> preemptive/cooperative scheduling<br>
><br>
> They're all separate concepts that might go together sometimes. Johannes point was about lack of support for cooperative scheduling in Swift, but he presented it as a sync API issue.<br>
<br>
</div>well, phrasing that as the lack of support for cooperative scheduling is a bit confusing I think. It's not that we're lacking the support to schedule cooperatively, it's the lack of having something that can be scheduled at all (in user-space). Call it fibers/coroutines/green threads or user-level threads. Whether the user-space scheduler is then cooperative or preemptive doesn't actually matter. What matters is that we can switch from one thread of execution to another cheaply (aka in user space). Libdill/mill/venice implement a user-level scheduler that is indeed cooperative but they require a basic mechanism to switch "user-level threads" which is setjmp/longjmp which is officially unavailable.<br>
<br>
That's why I phrased the problem as not being able to have a synchronous API (read() returns the bytes as its return value) that is non-blocking (doesn't block the current kernel thread).<br>
<br>
Please apologise for the nitpicking but I thought now introducing a third axis (scheduling) might lead to more confusion.<br>
<br>
--<br>
Johannes<br>
<div class="elided-text"><br>
><br>
><br>
> On Tue, May 30, 2017, 13:39 Michael Chiu <<a href="mailto:hatsuneyuji@icloud.com">hatsuneyuji@icloud.com</a>> wrote:<br>
>> I don't quite see why we need (or should even offer) a synchronous API for anything that involves IO (disk, network, ...). Sure, many of us would like to have a synchronous and non-blocking programming model, that'd be great. Today in Swift unfortunately we can only go asynchronous&non-blocking or synchronous&blocking (causing undefined behaviour [1] with setjmp/longjmp to get synchronous&non-blocking is cool but certainly not supported today).<br>
><br>
> I’m a bit confused here, synchronous&non-blocking can be done by kqueue/epoll/select/poll in swift.<br>
><br>
> It is true that kqueue and epoll are some low level C API but not having synchronous API basically screwed everyone who prefer to do their own scheduling for whatever reason.<br>
><br>
> Michael<br>
<br>
<br>
</div></blockquote></div><br></div></div>