[swift-server-dev] Prototype of the discussed HTTP API Spec

[Paulo Faria]

> Please apologise for the nitpicking but I thought now introducing a third
axis (scheduling) might lead to more confusion.

Haha, you actually introduced a fourth axis. And thank you for that. It
enlightened my view of the subject.

sync/async API
blocking/non-blocking IO
preemptive/cooperative Scheduling
kernel-space/user-space Context switching

And it shouldn't be confusing. People should know these concepts are all
distinct.

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:

user-space cooperative context switching with non-blocking synchronous APIs
vs kernel-space preemptive context switching with non-blocking asynchronous
APIs

I'll say *user-space cooperative context switching with non-blocking
synchronous APIs* any time of day, haha.


On May 30, 2017 14:38, "Johannes Weiss" <johannesweiss at apple.com> wrote:


> On 30 May 2017, at 5:44 pm, Paulo Faria <paulo at zewo.io> wrote:
>
> Yeah, it's important to distinguish:
>
> sync/async APIs
> blocking/nonblocking IO
> preemptive/cooperative scheduling
>
> 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.

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.

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).

Please apologise for the nitpicking but I thought now introducing a third
axis (scheduling) might lead to more confusion.

--
  Johannes

>
>
> On Tue, May 30, 2017, 13:39 Michael Chiu <hatsuneyuji at icloud.com> wrote:
>> 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).
>
> I’m a bit confused here,  synchronous&non-blocking can be done by
kqueue/epoll/select/poll in swift.
>
> 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.
>
> Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170530/9e2e4b1d/attachment.html>