[swift-server-dev] Next HTTP API meeting

[Johannes Weiß]

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