Implement asynchronous shutdown #183
Conversation
| /// callback instead of an EventLoopFuture. The reason for that is that NIO's EventLoopFutures will call back on an event loop. | ||
| /// The virtue of this function is to shut the event loop down. To work around that we call back on a DispatchQueue | ||
| /// instead. | ||
| public func shutdown(_ callback: @escaping (Error?) -> Void) { |
There was a problem hiding this comment.
Please don’t default to .global and take a DispatchQueue instead. A user who wants async shutdown will know what queue they want to be called on and it’s very likely not going to be `.global
There was a problem hiding this comment.
sure, one question is though: should EventLoopGroup do the same?
|
CC @adtrevor , mind taking a look at the new async shutdown? |
|
@swift-server-bot test this please |
1 similar comment
|
@swift-server-bot test this please |
|
|
||
| return EventLoopFuture.andAllComplete(connectionProviders.map { $0.close() }, on: eventLoop).map { | ||
| self.connectionProvidersLock.withLock { | ||
| assert(self.connectionProviders.count == 0, "left-overs: \(self.connectionProviders)") |
There was a problem hiding this comment.
I'm not 100% sure: if the check is delayed there might be cases where the assertion would have triggered but does not anymore. Even if true, I don't know how much important it is because the order/synchronization of the close actions will need to be improved anyway as we are already aware of issues linked to this in #175 and #176
There was a problem hiding this comment.
Ok, I'll look into that when I'll get to those issues, thanks!
Motivation:
Most NIO-based client implementation provide asynchronous shutdown method, we need to provide one as well. Closes #126
Modifications:
closeandprepareClosemethods in pool and connection providers to be asynchronous.closeandprepareClosein pool and connection providers on event loop.Result:
Client of the library can now use asynchronous shutdown when required.