[WIP] diagnostics_channel: add meta buil-in channels#61943
[WIP] diagnostics_channel: add meta buil-in channels#61943simon-id wants to merge 2 commits intonodejs:mainfrom
Conversation
Signed-off-by: simon-id <simon.id@protonmail.com>
|
@BridgeAR I am absolutely finishing this, but I'm still struggling to compile this for some reason. Started with fresh repo and all but can't get any usable compilation error message, so I'm working blind currently. I'll try to get it to compile on a colleague's machine next week 👍 |
Qard
left a comment
There was a problem hiding this comment.
Seems reasonable. It would be good to see a benchmark of the impact on a publish without subscribers though.
Publish on an inactive channel was intentionally a no-op to have the least possible performance impact when a channel does not have subscribers. With this it has at least an extra hasSubscribers check, and possibly a very noisy publish.
My worry with capturing all publishes everywhere automatically is that if a lot of channels exist, which is encouraged by diagnostics_channel, the performance impact could be substantial. I think I would prefer to have a special channel to publish to whenever a new channel is created. That way you could just listen to that and decide for each channel if you want to attach a subscriber to capture all events from it.
|
Yeah I don't like changing the noop of the inactive channel publish either. As you said, it would probably defeat the whole performance point of DC as a whole. I'll go another route. The problem with your alternative approach is that a "meta-observer" would be in a race condition with the channels being created. To be able to observe a channel, it would have to listen to it before it is created, which could happen in a completely different part of the code. So I don't like this approach too much either. I'll think about it a bit more 👍 |
|
You can special-case subscriptions for the meta-channel such that whenever a subscription is added it replays channel creation events for every already existing channel in the channel map. That'd eliminate the race condition. |
What
This add DC (
diagnostics_channel) built-in events, for DC itself. Just likehttp,console, orprocess, have built-in events that can be subscribed to, to monitor code, this make it possible for DC to be monitored through DC.Why
It appeared that multiple people working with DC channels extensively ended up monkey-patching DC in their test app or test suite, to allow some actions to be logged. Now instead of monkey-patching, they can just listen to these events.
It also allows one to create a kind of "dead-letter queue" DC subscription, that will catch all events that were not delivered: