Trivial context and comments

[anacrolix]

I've noticed a lot of locks around to ensure notification ordering. I think it's much superior to do synchronous notifications and allow consumers to decide for themselves how to handle concurrency. I've tested this significantly with the DHT, where it also provides for a lot of simplification. There is a fair bit of notification flow where go routines are spawned at each handler step, as an example.

[Stebalien]

This will break the connect events before disconnect events invariant.

[anacrolix]

I've removed the notification stuff, and just left the trivial stuff in.

[Kubuxu]

Another option might be to require the consumer of the API to provide a channel where notifications will be sent to. This channel has to have enough capacity to not block notification goroutine, otherwise, notification will be dropped.

It changes the semantics around notifications and might be problematic.

[anacrolix]

@Kubuxu I don't understand why the notifications must be asynchronous. Let the consumer control the concurrency situation.

[raulk]

@Kubuxu that approach sounds reasonable, but I don't trust the Notifee to not close the channel before time. If they do, the system will panic and it gets ugly. And a Notifee can be anything, i.e. user code.

[Kubuxu]

I don't understand why the notifications must be asynchronous. Let the consumer control the concurrency situation.

because one misbehaving consuming system affects the performance of the whole application

I don't trust the Notifee to not close the channel before time

This is API contract you have to make with your users with clean docs. There are multiple ways to achieve similar results when users miss uses an API (for example, taking a pointer to a variable and not copying it).

Not blocking this PR, just pointing out a possible alternative.