[swift-server-dev] Next HTTP API meeting

[Chris Bailey]

That certainly looks like an elegant approach to abstracting the API style 
away from the user :-)

>> Admittedly that wouldn't help build a libuv based solution - but at 
some point we will need to be opinionated, and saying that Dispatch is the 
concurrency/async framework shouldn't be too contentious. 

> I have some concerns about that, but maybe solely rooted in missing 
knowledge. Does GCD really scale well enough? I mean it was invented for 
client applications, that is to handle some queues, a few threads, and 
maybe some hundreds or thousands of async blocks. In a server application 
that would go up a lot …

Certainly when we compare benchmarks of the more well know Swift 
frameworks, most of which take different approaches to concurrency, those 
based on Dispatch don't appear to come out badly.

Dave Grove et al. have done testing of Dispatch on 12 core (plus 
hyperthreading) machines and don't see any scalability issues. IIRC there 
are some challenges in dealing/reacting to workloads that block because of 
the lag time to detect and schedule a new thread. 

> This is a place where (stream) protocols may be neat (make 
(Dispatch)Queue a protocol instead of a concrete implementation, etc). 
Then you could hook in other approaches, like uv, etc.

We could certainly do this - make Dispatch conform to a protocol (or wrap 
it in something that does) - but as you say "more options are not 
necessarily better". As it stands, Dispatch is the de-facto concurrency 
framework for Swift and is widely adopted in the Swift core libraries and 
existing Swift modules. Plugging in alternative approaches means that in 
any given application there's likely to be more that one concurrency 
library - for example, libuv for the web framework, and Dispatch being 
used in URLSession for outbound REST calls.

There is talk of revisiting Swift concurrency for in the Swift 4->5 time 
frame, but giving the existing investment and skills in Dispatch (and the 
challenges with implementing a CSP approach that Johannes mentioned) I 
would expect that this would reuse Dispatch technology but with more 
integration in terms of language keyworks and APIs (formal support for 
Promises/Futures?).

> I don’t care too much, but I think it may be worth a consideration to 
keep this open. Along the lines of Johannes' API, which can be even 
implemented in Apache ...

I can see support for sync and async approaches, but not necessarily the 
value for pluggable async concurrency frameworks vs. a concrete 
implementation. 

Chris




From:   Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To:     swift-server-dev <swift-server-dev at swift.org>
Date:   04/04/2017 18:44
Subject:        Re: [swift-server-dev] Next HTTP API meeting
Sent by:        swift-server-dev-bounces at swift.org



On 4. Apr 2017, at 15:31, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
> Is there anything preventing us from creating streams that support both 
sync and async APIs? NSStream provide both sync APIs, and the ability to 
provide async APIs by scheduling the stream on to a RunLoop.

I guess the only thing speaking against it is that more options are not 
necessarily better (rose-gold MacBookPro? bah!). If there is a sync API, 
reuse potential certainly increases.


Something I’ve been thinking of doing in an own framework in which I want 
to support both styles is a pair of protocols:

  protocol SyncFetcher {
    func fetch(sql: String, cb: ( Record ) -> Void)
    func async() -> AsyncFetcher
  }
  extension SyncFetcher {
    func sync()  -> SyncFetcher { return self }
  }
  protocol AsyncFetcher {
    func fetch(sql: String, @escaping cb: ( Record ) -> Void)
    func async() -> AsyncFetcher // returns self
    func sync() -> SyncFetcher
  }
  extension ASyncFetcher {
    func async()  -> AsyncFetcher { return self }
  }

The user code looks exactly the same

  fetcher.fetch { record in
    ..
  }

but he could decide between the imps by calling

  fetcher.async.fetch { …
  }

etc. The object implementing the protocol would know which style it 
supports (or both) and resort to the other style via either barriers 
(async->sync) or by using a worker queue (sync->async).

The advantage is that sync stacks can avoid the escape-overhead and that 
the usage would be type safe (e.g. the sync setup would guarantee that you 
can’t pass out closure you received for later processing - which is neat 
for middleware `next` callbacks). That makes sense even in async 
frameworks in scenarios where the user knows (and can get compiler 
guarantee) that he is not escaping closures.


> We could take a similar approach allowing you to assign a serial 
DispatchQueue.

What do you mean by that?


> Admittedly that wouldn't help build a libuv based solution - but at some 
point we will need to be opinionated, and saying that Dispatch is the 
concurrency/async framework shouldn't be too contentious. 

I have some concerns about that, but maybe solely rooted in missing 
knowledge. Does GCD really scale well enough? I mean it was invented for 
client applications, that is to handle some queues, a few threads, and 
maybe some hundreds or thousands of async blocks. In a server application 
that would go up a lot …

This is a place where (stream) protocols may be neat (make (Dispatch)Queue 
a protocol instead of a concrete implementation, etc). Then you could hook 
in other approaches, like uv, etc.

I don’t care too much, but I think it may be worth a consideration to keep 
this open. Along the lines of Johannes' API, which can be even implemented 
in Apache ...

hh

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170404/3accb5ff/attachment.html>