<font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Chris</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Johannes Weiß 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">Helge Heß <me@helgehess.eu></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</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">30/03/2017 16:07</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>Hi Helge,<br>
<br>
> On 30 Mar 2017, at 15:43, Helge Heß via swift-server-dev <swift-server-dev@swift.org>
wrote:<br>
> <br>
> On 30 Mar 2017, at 16:28, Johannes Weiß <johannesweiss@apple.com>
wrote:<br>
>> I meant trivial as in easy to create once, not in easy to create
the code. A function<br>
>> <br>
>> func synchronise<T>(_ func: ((T) -> Void) -> Void)
-> T<br>
>> <br>
>> which is easy to write might help though.<br>
> <br>
> Well, yes, this is easy exactly the other way around :-) I’ve done
this:<br>
> <br>
> </font></tt><a href=https://github.com/NozeIO/Noze.io/blob/master/Sources/fs/Directory.swift#L12><tt><font size=2>https://github.com/NozeIO/Noze.io/blob/master/Sources/fs/Directory.swift#L12</font></tt></a><tt><font size=2><br>
> <br>
> public func readdir(_ path: String, cb: @escaping ( [ String
]? ) -> Void) {<br>
> module.Q.evalAsync(readdirSync, path, cb)<br>
> }<br>
> public func readdirSync(_ path: String) -> [ String ]? {
.. }<br>
> <br>
> I’d claim the reverse, it is often easier to go from sync to async.
Dispatching on a GCD queue is trivial :-)<br>
<br>
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.<br>
<br>
<br>
>> AFAIK, libmill and friends all use setjmp/longjmp which is unsupported
in Swift anyway and might/will break<br>
> <br>
> 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?<br>
<br>
can you expand what would make that incompatible with what I proposed?<br>
<br>
-- <br>
Johannes<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>