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

[Johannes Weiss]

> 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