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

[Paulo Faria]

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

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.

> 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!

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.

On 30 May 2017 at 12:05, Johannes Weiss <johannesweiss at apple.com> wrote:

> Hi Paulo,
>
> > On 30 May 2017, at 4:00 pm, Paulo Faria <paulo at zewo.io> wrote:
> >
> > 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.
>
> 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!
>
>
> > 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.
>
> 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.
>
> --
>   Johannes
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170530/4b980f49/attachment.html>