MultiThreadedEventLoopGroup: allow users to specify the thread name pattern #2473
Comments
### 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
|
So the whole code infrastructure for this is already implemented in #2471: https://github.com/apple/swift-nio/pull/2471/files#diff-4b1291d44c519e5e77e9d2d3f165562ca65b739df1286327c5a0b0e1b5e98ff1R199 It's the API design that is the challenging part? I'm happy to poke you (and @glbrntt) with a pull request with a draft — that tends to spawn pretty fun discussions, it seems 🙃 (At least fun for me)
As in, automatically default to something other than |
|
I do not believe it is possible to get the module name of the invoking module. |
see also: https://forums.swift.org/t/pitch-introduce-module-to-get-the-current-module-name/45806 |
Right now, MTELG's thread name pattern is always
NIO-ELT-x-#y. TheNIO-ELT-part should be configurable by the user. AndNIOSingletons's ELG's (once #2471 is in) should set that to something useful.The text was updated successfully, but these errors were encountered: