[swift-server-dev] Next HTTP API meeting

[Chris Bailey]

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.

We could take a similar approach allowing you to assign a serial 
DispatchQueue. 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.

Chris



From:   Johannes Weiß via swift-server-dev <swift-server-dev at swift.org>
To:     Helge Heß <me at helgehess.eu>
Cc:     swift-server-dev <swift-server-dev at swift.org>
Date:   30/03/2017 16:07
Subject:        Re: [swift-server-dev] Next HTTP API meeting
Sent by:        swift-server-dev-bounces at swift.org



Hi Helge,

> On 30 Mar 2017, at 15:43, Helge Heß via swift-server-dev 
<swift-server-dev at swift.org> wrote:
> 
> On 30 Mar 2017, at 16:28, Johannes Weiß <johannesweiss at apple.com> wrote:
>> I meant trivial as in easy to create once, not in easy to create the 
code. A function
>> 
>> func synchronise<T>(_ func: ((T) -> Void) -> Void) -> T
>> 
>> which is easy to write might help though.
> 
> Well, yes, this is easy exactly the other way around :-) I’ve done this:
> 
>  
https://github.com/NozeIO/Noze.io/blob/master/Sources/fs/Directory.swift#L12

> 
>  public func readdir(_ path: String, cb: @escaping ( [ String ]? ) -> 
Void) {
>    module.Q.evalAsync(readdirSync, path, cb)
>  }
>  public func readdirSync(_ path: String) -> [ String ]? { .. }
> 
> I’d claim the reverse, it is often easier to go from sync to async. 
Dispatching on a GCD queue is trivial :-)

well, both aren't too hard but I believe DispatchQueues aren't a great 
place to do blocking IO on. There's a limited number of threads (that you 
don't directly control) and you wouldn't want to sacrifice one of those 
per request, right? But I agree it's possible easily too.


>> AFAIK, libmill and friends all use setjmp/longjmp which is unsupported 
in Swift anyway and might/will break
> 
> OK, lets assume that the Go approach won’t be supported (or pure 
synchronous IO like in Apache). This still leaves us with alternative 
async I/O frameworks. E.g. I’d potentially like to use libuv in Noze.io 
and replace GCD channels with that. Or do you want to standardise this 
effort on GCD?

can you expand what would make that incompatible with what I proposed?

-- 
  Johannes
_______________________________________________
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/dba51d55/attachment.html>