Could we deal with executors in a more modular way?

[thomaseizinger]

At the moment, we have this notion of spawning tasks on an executor and thus have to differentiate, which executor we spawn these on.

That isn't very modular and it makes it difficult for users to add custom functionality in. For example, Lighthouse has a custom executor to spawn tasks with some metrics added to them: sigp/lighthouse#4695 (comment)

When thinking about this, I figured we could also do the following:

enum SwarmEvent {
	Behaviour(...),
	// ....
	SpawnTask(Task) // <-- This is new.
}

struct Task {
	// whatever we want to run on an executor
}

impl Future for Task { }

The downside of this proposal is that users must handle this event, i.e. it is present in every event-loop. On the upside, this makes a Swarm executor agnostic.

[umgefahren]

Why is it not enough to pass a custom executor via libp2p_swarm::Config::with_executor? I thought that's the whole purpose of the API.

If the API is missing from SwarmBuilder, we could just add that.

[thomaseizinger]

It is indirection that forces us to add a lot of conditional code because we need to call something for the user. That is a more framework-y approach (i.e. "we call you").

The proposal here is more library-style, i.e. "you call us". (via Swarm::next which the user must do already anyway).

[thomaseizinger]

The advantage of the latter is that users can instrument these tasks however they want instead of us needing to offer hooks to instrument them.