<font size=2 face="sans-serif">That certainly looks like an elegant approach
to abstracting the API style away from the user :-)</font>
<br>
<br><tt><font size=2>>> 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. <br>
<br>
> 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 …<br>
</font></tt>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br><tt><font size=2><br>
> 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.<br>
</font></tt>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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?).</font>
<br><tt><font size=2><br>
> 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 ...</font></tt>
<br>
<br><font size=2 face="sans-serif">I can see support for sync and async
approaches, but not necessarily the value for pluggable async concurrency
frameworks vs. a concrete implementation. </font>
<br>
<br><font size=2 face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Helge Heß via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">swift-server-dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">04/04/2017 18:44</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Next HTTP API meeting</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 4. Apr 2017, at 15:31, Chris Bailey <BAILEYC@uk.ibm.com>
wrote:<br>
> 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.<br>
<br>
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.<br>
<br>
<br>
Something I’ve been thinking of doing in an own framework in which I want
to support both styles is a pair of protocols:<br>
<br>
protocol SyncFetcher {<br>
func fetch(sql: String, cb: ( Record ) -> Void)<br>
func async() -> AsyncFetcher<br>
}<br>
extension SyncFetcher {<br>
func sync() -> SyncFetcher { return self }<br>
}<br>
protocol AsyncFetcher {<br>
func fetch(sql: String, @escaping cb: ( Record ) -> Void)<br>
func async() -> AsyncFetcher // returns self<br>
func sync() -> SyncFetcher<br>
}<br>
extension ASyncFetcher {<br>
func async() -> AsyncFetcher { return self }<br>
}<br>
<br>
The user code looks exactly the same<br>
<br>
fetcher.fetch { record in<br>
..<br>
}<br>
<br>
but he could decide between the imps by calling<br>
<br>
fetcher.async.fetch { …<br>
}<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
> We could take a similar approach allowing you to assign a serial DispatchQueue.<br>
<br>
What do you mean by that?<br>
<br>
<br>
> 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. <br>
<br>
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
…<br>
<br>
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.<br>
<br>
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 ...<br>
<br>
hh<br>
<br>
_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>