[swift-server-dev] Proposal: Structs in place of a request-handling function

[George Leontiev]

@Cory
I do, in fact, mean “zero allocations per request”. I think this is a good thing to strive for, whether as a hard rule or as goal. With regard to your question about parsing, I’ve pushed a prototype of a zero-allocations wrapper for http_parser.c here <https://github.com/GeorgeLyon/SwiftHTTPParser>. There’s a few issues I still need to work through but I think it is enough to communicate the overall gist.

@Helge
I’m handwaving the actual HTTP writing part, but echo and async examples can be found in main.swift <https://github.com/GeorgeLyon/Server/blob/master/Sources/Server/main.swift> now. They are not meaningfully dissimilar from the ones you provided. I would argue avoid the return-a-closure semantic makes them cleaner, but that is just my opinion. 

As for back pressure, could you provide a specific use case? It isn’t that I don’t believe back pressure is important, just that there are many places where it can be handled. For instance, the top-level Server object can have a maximum number of open connections of a particular type, or what is now the HTTPWriter can be something else which has a “applyBackpressure” method which synchronizes with the Server under the hood (think wrapping the DispatchQueue argument in your PR in a struct which does `queue.async{ applyBackpressure() }`) without revealing the queue to the handler.


> On Dec 11, 2017, at 2:59 AM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 11. Dec 2017, at 02:27, George Leontiev via swift-server-dev <swift-server-dev at swift.org> wrote:
>> With the current design, we effectively guarantee at least one allocation per request because we process the body by returning a closure.
> 
> Well, while I like the premise, there are *so* many allocations in the current setup (just think about all the Strings in the HTTPRequestHead), this one should really be the last we care about :-)
> 
> 
> As mentioned before I don’t particularly like the current API, but it is something people could agree on and which I think can do what higher level frameworks require. I’m also fine w/ using a protocol. But it should support the same functionality (or at least allow it at a higher level).
> 
> What I miss in your suggestion is a demo on how something complete would look like. I.e., what does the `echo` look like:
> 
>  https://github.com/ZeeZide/http-testserver/blob/master/Sources/http-testserver/main.swift#L54
> 
> and how would the async wait look like:
> 
>  https://github.com/ZeeZide/http-testserver/blob/master/Sources/http-testserver/main.swift#L111
> 
> A demo of an echo w/ back-pressure would be cool too.
> 
> Note: I’m not expecting working examples here, I would just like to see how you think those would look like in your API.
> 
> Thanks,
>  Helge
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20171216/7ecca217/attachment.html>