Standard Way of Expressing Shared vs. Internal EventLoopGroup

[Mordil]

As we've seen so far in the SSWG pitches/proposals for the nio-postgres (nio-redis initially modeled after this proposal) and nio-http packages there's been this idea of NIO-based library authors providing a means to users to either pass in their own EventLoopGroup they might intend to share, but still maintain ownership over the lifecycle, or to let the library decide that detail for itself.

NIORedis used to have an implementation and this was previously proposed as a part of NIO core but was rejected as it was too broad of a solution to be in NIO proper.

Could this have a home here? (bikeshedding the naming, of course)

public enum EventLoopGroupProvider {
    // library is given access to use this as a resource, but is not allowed to manage the lifecycle
    case shared(EventLoopGroup)
    // library is left to decide for itself how to create one as an implementation detail
    // and is fully responsible for this resource
    case createNew
}

perhaps a third case could be given that is .unique(EventLoopGroup) for the cases where a library might be the one that wants to provide EventLoopGroups, but that it's giving ownership of it to whoever is asking for an EventLoopGroupProvider?

[Mordil]

Honestly, this request could be chalked up to a reflective "This isn't DRY!" seeing a few different modules all proliferating their own enum types when they all work with the same underlying value of passing NIO EventLoop or EventLoopGroup

[weissi]

@Mordil thanks! .unique(...) isn't necessary because each EventLoop is also an EventLoopGroup. So could do can do .shared(myEventLoop).

So I think I'd be happy for this to be in NIOExtras. After all, it's our incubation repo.

@normanmaurer / @Lukasa WDYT?

[Lukasa]

Works for me.

[glbrntt]

This was resolved by https://github.com/apple/swift-nio/pull/1609