Add ThreadOwnershipModel enum
#810
Conversation
|
Can one of the admins verify this patch? |
3 similar comments
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
Motiviation: As discussed in the pitch for NIORedis and NIOPostgres (https://forums.swift.org/t/swiftnio-redis-client/19325 and https://forums.swift.org/t/pitch-swiftnio-based-postgresql-client/18020), an idea has been floated of providing a `ThreadOwnership` model to provide capabilities of these libraries to be used "out of the box" without having to think about setting up and maintaining EventLoopGroups by end users. It might be useful to have this type be defined in NIO itself, so as framework and library authors can share this type and reference it in whatever features they may want to build. An example of use can be found in NIORedis at https://github.com/Mordil/nio-redis/blob/e168b6c65eb471e186fd43623af93a4902564756/Sources/NIORedis/RedisDriver.swift Modifications: Added a `ThreadOwnershipModel` public enum with two cases: `internal` and `external` Results: A new enum type that implementers can use to define how their types can be used to manage NIO threading resources.
Mordil
force-pushed
the
ownership-model
branch
from
7cb805f
to
cdb35d4
Compare
There was a problem hiding this comment.
Thanks for opening this and for the suggestion!
However, I'm a -1 on this idea. While I understand the desire to standardise around the interface for this kind of thing, I think this is a substantial oversimplification of the problem that, while suitable for NIORedis and NIOPostgres in the current moment, is not going to age well.
In particular, the "thread ownership model" here suggests that all event loop groups are equal, which they are not. In particular, the EventLoopGroup existential provided here is not actually useful, as it must always be conditionally downcast to a usable data type (e.g. MultiThreadedEventLoopGroup).
I think any attempt to standardise something like this will need to first address the proliferation of Bootstraps. This will likely require defining one or more protocols that indicate the baseline of what a bootstrap actually supports, along with providing associated types that indicate what type of event loop group is required for a given bootstrap.
With sufficient care we should be able to design a model that will allow libraries to express much more clearly what kinds of event loop groups they support or require, as well as encompass some notion of a thread ownership model.
For the moment, though, I'm fine with this enum being repeated in a few different modules: it's only a few lines of code.
|
@Lukasa That's definitely reasonable - especially from NIO's perspective on the problem and solution. |
Motiviation:
As discussed in the pitch for NIORedis and NIOPostgres (https://forums.swift.org/t/swiftnio-redis-client/19325 and https://forums.swift.org/t/pitch-swiftnio-based-postgresql-client/18020),
an idea has been floated of providing a
ThreadOwnershipmodel to provide capabilities of these libraries to be used "out of the box" without having to think about setting up and maintainingEventLoopGroups by end users.
It might be useful to have this type be defined in NIO itself, so as framework and library authors can share this type and reference it in whatever features they may want to build.
An example of use can be found in NIORedis at https://github.com/Mordil/nio-redis/blob/e168b6c65eb471e186fd43623af93a4902564756/Sources/NIORedis/RedisDriver.swift
Modifications:
Added a
ThreadOwnershipModelpublic enum with two cases:internalandexternalResults:
A new enum type that implementers can use to define how their types can be used to manage NIO threading resources.