<html><body><p><font size="2">Hi, Tanner,</font><br><br><font size="2">When I'm writing SSS code for an iOS endpoint that talks to a back-end service, I'll often dispatch an URLSession.dataTask() to go ask the back-end for data, and then request/response handling occurs in the completion handler when the dataTask comes back.</font><br><br><font size="2">I find that to be a really common pattern when I'm working in an Enterprise and I have some kind of legacy service I need to talk to.</font><br><br><font size="2">-Carl</font><br><br><img width="16" height="16" src="cid:1__=8FBB0A63DFCEB20D8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Tanner Nelson via swift-server-dev ---03/27/2017 09:42:54 AM---@chris in my experience there's been v"><font size="2" color="#424282">Tanner Nelson via swift-server-dev ---03/27/2017 09:42:54 AM---@chris in my experience there's been very little passing of request/response between threads. Usuall</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Tanner Nelson via swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Chris Bailey <BAILEYC@uk.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/27/2017 09:42 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-server-dev] Next HTTP API meeting</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">swift-server-dev-bounces@swift.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>@chris in my experience there's been very little passing of request/response between threads. Usually the server accepts, spins up a new thread, and all HTTP parsing/serializing happens on that one thread. <br><br>Could you specify some examples where requests/responses are being passed between threads?<br><br>That said, it should be fairly easy to implement threading to see what the effects would be. I will look into that. :)<br><br>Tanner<br><br><font color="#9DACD1">Va</font><font color="#AEB2CF">p</font><font color="#C8BACD">o</font><font color="#D0BECC">r</font><font color="#9DACD1"> </font><br><a href="mailto:tanner@vapor.codes"><u><font color="#0000FF">tanner@vapor.codes</font></u></a><br>
<ul><ul>On Mar 27, 2017, at 3:37 PM, Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com"><u><font color="#0000FF">BAILEYC@uk.ibm.com</font></u></a>> wrote:<br><br><font size="2">Nice work!</font> <br><font size="2"><br>Taking a quick look at the project and screenshot, am I right in saying that there is no concurrency in the test? ARC generally has a bigger impact in concurrent use cases because of the need to keep memory consistency across processors for the atomic increment/decrement.</font> <br><font size="2"><br>How hard would it be to add a dispatch queue in?</font> <br><font size="2"><br>Chris</font> <br><br><br><font size="2" color="#5F5F5F"><br>From: </font><font size="2">Tanner Nelson via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org"><u><font size="2" color="#0000FF">swift-server-dev@swift.org</font></u></a><font size="2">></font> <font size="2" color="#5F5F5F"><br>To: </font><font size="2">Michael Chiu <</font><a href="mailto:hatsuneyuji@icloud.com"><u><font size="2" color="#0000FF">hatsuneyuji@icloud.com</font></u></a><font size="2">></font> <font size="2" color="#5F5F5F"><br>Cc: </font><font size="2">swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org"><u><font size="2" color="#0000FF">swift-server-dev@swift.org</font></u></a><font size="2">></font> <font size="2" color="#5F5F5F"><br>Date: </font><font size="2">27/03/2017 14:38</font> <font size="2" color="#5F5F5F"><br>Subject: </font><font size="2">Re: [swift-server-dev] Next HTTP API meeting</font> <font size="2" color="#5F5F5F"><br>Sent by: </font><a href="mailto:swift-server-dev-bounces@swift.org"><u><font size="2" color="#0000FF">swift-server-dev-bounces@swift.org</font></u></a> <br><hr width="100%" size="2" align="left" noshade><br><br><br>Re: performance, <br><br>I did a quick test of inout struct vs. class performance. The code can be found here: <a href="https://github.com/tanner0101/request-types"><u><font color="#0000FF">https://github.com/tanner0101/request-types</font></u></a> <br><br>I found only a marginal increase in performance (~5%) in favor of inout value types. <a href="https://github.com/tanner0101/request-types/issues/1"><u><font color="#0000FF">https://github.com/tanner0101/request-types/issues/1</font></u></a> <br><br>Additionally, non-inout value types were a lot slower. This is obvious to the seasoned Swift dev considering each middleware in the test modifies and thus must copy the request. But this is the exact type of performance issue you can expect developers to create when interacting with "non-obvious value types". HTTP request/response being non-obvious value types compared to something like an integer or a float. (I'd argue the majority of web developers would expect request/response to be a reference type and thus easily forget or not know to use `inout`) <br><br>Please feel free to submit any prs/issues/comments about ways I could improve this test to make it more accurate. <br><br>tl;dr: value types don't seem much faster than reference types (especially considering dangers of misuse) in a simulated web framework scenario <br><br>inb4: people saying that the request/response models in my test are incomplete/not fully implemented/bad. this is _not_ a proposed api for request/response. <br><font color="#9F9FE0"><br>Va</font><font color="#B1B1D2">p</font><font color="#C0C0C0">o</font><font color="#BFBFBF">r</font><font color="#9F9FE0"> </font><u><font color="#0000FF"><br></font></u><a href="mailto:tanner@vapor.codes"><u><font color="#0000FF">tanner@vapor.codes</font></u></a> <br><br>On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev <<a href="mailto:swift-server-dev@swift.org"><u><font color="#0000FF">swift-server-dev@swift.org</font></u></a>> wrote: <br><br><br>On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org"><u><font color="#0000FF">swift-server-dev@swift.org</font></u></a>> wrote:<br>If people feel extremely strong that there needs to be a concrete type, then I'd like to push for reference type as much as possible. As far as reference vs value type, I haven't really heard an argument for value types beyond what feels like a reaction to value types being the hip new hotness. While yes, they're great in Swift, and there's tons of places that should absolutely be modeled with value semantics, a request/response interaction represents a single request and should definitely be a reference based interaction. <br><br>I disagree with this one. First of all I think most of the framework pass the request and response as inout argument, if that is the case there shouldn’t be much copy overhead in the run loop. Second the problem of reference type is that everywhere the request and response exists could possibly mutate the res/req, and it affect globally. It is true that in normal use there shouldn’t be two place simultaneously operate on the same request but that could happen. (Therefore protocol is the best isn’t it)<br><br>In practice, we went through several model iterations and the value type created very high levels of bugs and confusion for end users. The three biggest problems we had were as follows:<br><br>- Greatly increased bug levels and confusion related to unexpected mutation<br>- Unnecessary code requirements added to every single passive access (ie: middleware) increasing code bloat unnecessarily<br>- Extreme performance loss due to massive copy overhead<br><br>Each of these problems evaporated pretty instantaneously when moving to reference types; it made it significantly easier to reason about for end users. <br>Just for curiosity, I’m very interested in the unexpected mutation of value semantic, I have always had an impression of value semantic are more free from unexpected mutation. <br><br>Would like to remind again for those that skipped above reading that our goal is not to build a web framework here, but rather to build small tools that make building frameworks slightly easier for library maintainers and creators. <br>That’s so true lol.<br><br>Michael.<br><br>_______________________________________________<br>swift-server-dev mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:swift-server-dev@swift.org"><u><font color="#0000FF">swift-server-dev@swift.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><u><font color="#0000FF">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></u></a> <tt><font size="2"><br>_______________________________________________<br>swift-server-dev mailing list</font></tt><tt><u><font size="2" color="#0000FF"><br></font></u></tt><a href="mailto:swift-server-dev@swift.org"><tt><u><font size="2" color="#0000FF">swift-server-dev@swift.org</font></u></tt></a><u><font color="#0000FF"><br></font></u><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><u><font size="2" color="#0000FF">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></u></tt></a><br><br><font size="2"><br><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</font></ul></ul><tt><font size="2">_______________________________________________<br>swift-server-dev mailing list<br>swift-server-dev@swift.org<br></font></tt><tt><font size="2"><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></font></tt><tt><font size="2"><br></font></tt><br><br><BR>
</body></html>