This repository was archived by the owner on Nov 23, 2021. It is now read-only.
Add optional queue to handler
#86
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For async servers, there has to be a synchronization point
for done callbacks. This is what the `queue` is for.
If the handler doesn't dispatch to other queues but stays
within the calling one, it doesn't need to call the done
callbacks via
queue.async { done() }
but can do a straight
done()
But if the handler does perform its work async, it need
to use the given queue to call the done, e.g.:
func workHard(req: HTTPRequest, res: HTTPResponseWriter, queue: DispatchQueue?) {
DispatchQueue.background.async {
// do hard work
queue.async {
res.writeHeader(status: .ok)
}
}
}
etc.
We are using `DispatchQueue` here. Another option is to add a
non-optional
HTTPSynchronizationContext protocol
(adapted by DispatchQueue or a uv or sync variant)
seabaylea
reviewed
Nov 7, 2017
| /// - queue: optional, if set, dispatch done callbacks back to this queue (if | ||
| /// the handler processing escapes the calling queue) | ||
| /// - Returns: HTTPBodyProcessing: a enum that either discards the request data, or provides a closure to process it. | ||
| public typealias HTTPRequestHandler = (HTTPRequest, HTTPResponseWriter, DispatchQueue?) -> HTTPBodyProcessing |
There was a problem hiding this comment.
On Linux you'll need to import Dispatch explicitly to have access to DispatchQueue
There was a problem hiding this comment.
Aside: from Swift 4.1 that won't be true, thanks to swiftlang/swift-corelibs-foundation#1206 🙂
There was a problem hiding this comment.
Though importing Foundation is non-sense in the first place, no Foundation is used here ;->
helje5
added a commit
to ZeeZide/http
that referenced
this pull request
Nov 10, 2017
Similar to PR swift-server#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.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For async servers, there has to be a synchronization point
for done callbacks. This is what the
queueis for.If the handler doesn't dispatch to other queues but stays
within the calling one, it doesn't need to call the done
callbacks via
but can do a straight
But if the handler does perform its work async, it need
to use the given queue to call the done, e.g.:
etc.
We are using
DispatchQueuehere. Another option is to add anon-optional
HTTPSynchronizationContext protocol
(adapted by DispatchQueue or a uv or sync variant)