Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
GCD based, Asynchronous Implementation of the API #96
This PR contains a GCD DispatchIO based implementation of the API and presumably should scale significantly better than the synchronous one. Throughput should be somewhat worse for obvious reasons.
Unlike Noze.io or Node.js it does not use a single network processing queue, but rather a set of base queues as suggested by Johannes. To support that, the handler API has been enhanced with the
This implementation is supposed to properly support back pressure and pipelining.
The little socket stuff we need we can do directly in the code. No need to wrap such basics. The StreamingParser was some combination of response writer and parser. Those are really distinct things (the writer doesn't really need to know about the parser, and the reverse).
Similar to PR #86. In this case it is non-optional, that thing being a concrete implementation. All API functions need to run on the given queue. But since the handler itself also runs on that queue, it only needs to be done if the handler actually dispatches to a different queue. This is an optimization to avoid excessive dispatching in async environments. (if API calls could be issued from arbitrary queues, they would always need to be queued to the handler queue. which is possible but pretty expensive). P.S.: The argument is necessary because there is nothing like `DispatchQueue.current` in GCD anymore.
It would be awesome if you would get the tests working again. I don't plan to work on such any time soon, so feel free to do anything you want!
Adjusting the tests might be challenging, because, well, they need to be asynchronous. For Noze.io I have a helper class which tries to deal with the asynchronicity, not sure whether it might help you or not (or even whether this is the correct way to test that stuff): NozeIOTestCase.swift
The other hurdle is that I made the
BTW: I also still wonder whether we would want to allow multiple implementations, or whether that is just bad for a basic core module. E.g. I can imagine that we might be able to use generics to efficiently do something like Apache MPMs, for example:
let asyncServer = HTTPServer<DispatchMPM>(port: ...)
let syncServer = HTTPServer<ThreadedMPM>(port: ...)
Both have their unique advantages and disadvantages. But maybe this would make it too complex, not sure.
Ok. Let me go to work on that, and we'll see how far I get.