NIOTSEventLoops don't participate in MTEventLoopGroup.currentEventLoop about swift-nio-transport-services

[Lukasa]

Exposing the currentEventLoop as public API (which is obviously undesirable; it would only be misused in the same way dispatch_get_current_queue() historically has been)

Stating this more strongly: I don't believe this is possible, irregardless of whether it's desirable.

I think a first step is: do we believe this problem has a generic solution at all? It's my understanding that in the absence of any context-propagation functionality within Dispatch it is simply not possible to implement a correct version of the "what event loop am I on" function with NIOTS.

Am I missing something?

[gwynne]

No, you're definitely correct. But it's possible there will eventually be API in Dispatch that allows for it (miracles do happen! 😆), and even if not, it doesn't negate that EventLoopGroup in the generic sense should have a more extensible abstraction for these particular kinds of preconditions. This was one of the intended eventual (if fringe) benefits of adding the ability to specify a failure message to EventLoop's precondition[Not]InEventLoop() methods, except the limitations of Dispatch forced me to withdraw that part of the pull request.

I absolutely do not believe that currentEventLoop should be exposed as public API, or really even as private API. But I do think there should exist a well-named, purpose-constrained abstraction that permits expressing the assertions that it's currently used for, in the same way that Dispatch provides the dispatch_assert_queue*() assertions without the need for dispatch_get_current_queue().