<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 30, 2017, at 12:02 PM, Johannes Weiss via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><div class=""><div class="">if you use kqueue/(e)poll/select you get inversion of control, ie. you block only one (or a few) threads in kqueue/epoll/select and then invoke code to handle the event (which can be 'file descriptor XYZ can be read/written').<br class=""><br class="">So the echo server becomes more like this (this is extreme pseudo code and ignores most of the real challenges)<br class=""><br class="">func echoServer(socket: Socket) {<br class=""> socket.whenReadable { bytes in<br class=""> socket.whenWritable {<br class=""> socket.write(bytes)<br class=""> }<br class=""> }<br class="">}<br class=""><br class="">If you want a more realistic example check out DispatchSources and DispatchIO from Dispatch. </div></div></blockquote><br class=""></div><div>For whatever it's worth, the implementation we posted uses DispatchSources for reading from the Socket (see <a href="https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/BlueSocketDriver/BlueSocketConnectionListener.swift#L166-L169" class="">https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/BlueSocketDriver/BlueSocketConnectionListener.swift#L166-L169</a>), although in my testing using an additional DispatchSource for writing didn't seem to affect the performance at all (but did increase complexity) so I pulled it out.</div><div><br class=""></div><div>I'd love to get more eyes on that code, if anyone has the time.</div><div><br class=""></div><div>-Carl</div><div><br class=""></div></body></html>