eventbus: subscribers should know if there are any emitters for a event/s

[aarshkshah1992]

Subscribers should be able to know if the eventbus has emitter for some event/s. This would allow the component housing the subscriber to close the subscriber if no emitters exist and execute some other code path if needed.

This would entail:

1. "Closing the eventbus" for registering emitters.
2. Informing the subscribers that the eventbus has been closed to emitters via a "meta-event" that interested subscribers subscribe to.
3. Subscribers would call Subscription.GetEmitters or something similar to find out if there are any emitters after receiving the "meta-event".

[aarshkshah1992]

@raulk Any thoughts ?

[yusefnapora]

I like this idea - just pasting in my thoughts from slack so they don't evaporate:

My only concern is dependency cycles, where one service wants to check if an event is being emitted before registering its own emitter. if two services were depending on each others events they would be blocking each other.

But we probably want to consider cycles like that a programmer error anyway, so it should be fine :)

[aarshkshah1992]

ping @Stebalien

[aarshkshah1992]

ping @raulk

[raulk]

So the design I had in mind is as follows:

1. EventBus exposes an EmitterCount(reflect.Type) int method through which a subscriber can enquire how many emitters are emitting a particular event type.
2. We introduce libp2p lifecycle events that are emitted directly by the host. A subscriber needing to know if emitters have been registered for a particular event (to vary its behaviour accordingly) would listen to these lifecycle events and query the EventBus via EmitterCount() accordingly:
   • Local{Host,Transports,Multiplexers,Peerstore,Protocol}Initializing
   • Local{Host,Transports,Multiplexers,Peerstore,Protocol}Initialized
   • Local{Host,Transports,Multiplexers,Peerstore,Protocol}Closing
   • Local{Host,Transports,Multiplexers,Peerstore,Protocol}Closed

^^ ideally I'd like to reach this level of granularity. This would work pretty well with dependency injection (uber/fx) in the future. But on a first iteration, the Host variants should suffice.

[Stebalien]

Update: We've punted this for now in favor of using a single event that optionally includes the signed record. We still want to be able to react to available events, but we don't have to tackle this question now.