[Pitch] Custom Main and Global Executors

[FranzBusch]

@al45tair

Perhaps, but I don't think Span is ready yet? (That's why I went with some Collection<Int> — though it could have been some Collection<UInt8>.) Maybe I'm wrong and we could use it here?

The proposal has been accepted so I think we can start using it [Accepted] SE-0447: Span: Safe Access to Contiguous Storage.

@al45tair

An example where the C++ equivalent is presently in use is in the Dispatch-based global executor, if you specify a deadline with a tolerance, the executor creates a Dispatch timer source and allocates, using the allocator we're exposing here, a small control block to hold a pointer to the job itself and the timer source; this block is used as the context pointer for the timer source, which lets the callback clear up the source and the control block before triggering the job's execution.

Thanks that's super helpful. If we could add something like as a brief example to the proposal that would help a lot with understanding why we need it.

@al45tair

We thought about this previously and discarded it, partly because it makes it hard to control which executor you're using from a command line argument or environment variable.

I think this is the same argument as the Epoll vs IOUring executor. It can also be worked around by having a DynamicExecutorFromArguments or similar.

@al45tair

The point here is that you can have e.g. an IOUringExecutor, an EpollExecutor and a SelectExecutor and select which one you wish to use dynamically. Making the choice of executor fully static means wrapping them all up into some kind of UberExecutor, which sounds like not such a great pattern — mostly it would exist to work around the fact that we'd forced the executor choice to be statically determined.

I personally feel like it is worth to statically encode that the executor can be set once and require users to create such dynamic executors that are configured by reading the environment or doing feature detection. For example, having a NIOExecutor that does feature detection at runtime to determine the underlying strategy seems totally reasonable to me.
FWIW, this isn't something that I feel super strong about. If we feel the ergonomics are better by doing runtime detection of setting the executor more than once that's also totally fine.