NIOSingletonsTransportServices: Use NIOTS in easy mode #180
Conversation
|
This cannot be merged until apple/swift-nio#2471 has been released in NIO 2.57.0 |
weissi
force-pushed
the
jw-nio-singletons
branch
from
a2c4ef3 to
dfba0e5
Compare
### Motivation: SwiftNIO allows and encourages to precisely manage all operating system resources like file descriptors & threads. That is a very important property of the system but in many places -- especially since Swift Concurrency arrived -- many simpler SwiftNIO programs only require a single, globally shared EventLoopGroup. Often even with just one thread. Long story short: Many, probably most users would happily trade precise control over the threads for not having to pass around `EventLoopGroup`s. Today, many of those users resort to creating (and often leaking) threads because it's simpler. Adding a `.globalSingle` static var which _lazily_ provides singleton `EventLoopGroup`s and `NIOThreadPool`s is IMHO a much better answer. Finally, this aligns SwiftNIO a little more with Apple's SDKs which have a lot of global singletons that hold onto system resources (`Dispatch`'s thread pool, `URLSession.shared`, ...). At least in `Dispatch`'s case the Apple SDKs actually make it impossible to manage the resources, there can only ever be one global pool of threads. That's fine for app development but wouldn't be good enough for certain server use cases, therefore I propose to add `NIOSingleton`s as an _option_ to the user. Confident programmers (especially in libraries) are still free and encouraged to manage all the resources deterministically and explicitly. Companion PRs: - apple/swift-nio-transport-services#180 - swift-server/async-http-client#697 ### Modifications: - Add the `NIOSingletons` type - Add `MultiThreadedEventLoopGroup.singleton` - Add `NIOThreadPool.singleton` ### Result: - Easier use of NIO that requires fewer parameters for users who don't require full control. - Helps with #2142 - Fixes #2472 - Partially addresses #2473
weissi
force-pushed
the
jw-nio-singletons
branch
from
dfba0e5 to
a775e12
Compare
weissi
force-pushed
the
jw-nio-singletons
branch
from
a775e12 to
bf033da
Compare
weissi
force-pushed
the
jw-nio-singletons
branch
2 times, most recently
from
520b4a6 to
1c2b27e
Compare
|
With the NIO 2.58.0 release this should now go green |
weissi
force-pushed
the
jw-nio-singletons
branch
from
64b8f90 to
944225e
Compare
|
@Lukasa merging is currently blocked because it still has you down as a 'request changes', at your convenience PTAL |
| } | ||
|
|
||
| @available(OSX 10.14, iOS 12.0, tvOS 12.0, watchOS 6.0, *) | ||
| extension EventLoopGroup where Self == NIOTSEventLoopGroup { |
There was a problem hiding this comment.
Does this extension ever exist where the other does not?
There was a problem hiding this comment.
@Lukasa , @glbrntt suggested this one. The answer is yes, in the many places where we take any EventLoopGroup. there you can now type .singletonMultiThreadedEventLoopGroup/.singletonTransportServicesEventLoopGroup.
I don't know if I love it but NIO released this pattern and even if we decided that it's bad, it's an easy one to deprecated. Given that it's in NIO we should also have it in TS.
There was a problem hiding this comment.
FWIW I think this is the more useful API for most users because it's easy to discover: IDEs will suggest this when you dot-tab-complete for any EventLoopGroup. If you didn't have this API users would have to know about the ELG types or singleton objects to find them.
There was a problem hiding this comment.
I think we have SwiftUI to thank for this 😃 e.g. https://developer.apple.com/documentation/swiftui/view/labelstyle(_:)
Motivation:
(companion PR to apple/swift-nio#2471)
SwiftNIO allows and encourages to precisely manage all operating system resources like file descriptors & threads. That is a very important property of the system but in many places -- especially single Swift Concurrency arrived -- many simpler SwiftNIO programs only require a single, globally shared EventLoopGroup. Often even with just one thread.
Long story short: Many, probably most users would happily trade precise control over the threads for not having to pass around
EventLoopGroups. Today, many of those users resort to creating (and often leaking) threads because it's simpler. Adding singletons type which lazily provide a singletonEventLoopGroupand anNIOThreadPoolis IMHO a much better answer.Modifications:
NIOTSEventLoopGroup.singletonNIOSingletons.transportServicesEventLoopGroupResult: