
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m curious how this is different from gen_event (<a href="http://erlang.org/doc/man/gen_event.html" class="">http://erlang.org/doc/man/gen_event.html</a>) and how you deal with the need to supervise restart of failed handlers. I guess one big difference is that you crash the caller on the first handler error, skipping the remaining ones, whereas gen_event shields the caller and removes the callback on first failure. gen_event allows both asynchronous and synchronous notifications, and also the benefit of using the sys tools and debug that gen_event brings, plus the ability of handlers to invoke hibernate to save memory under specific circumstances.<div class=""><div class=""><br class=""></div><div class="">I’m not sure at what point using ets over an in memory gen state is worthwhile in terms of number of callbacks. I assume that is the main point, but I’m guessing it would take 10K to 100K before it was noticeable during garbage collection. Adding handlers is bottlenecked on the gen_server the same as gen_event, so maybe there is a speedup when looking up a handler (although duplicate_bag may not be super fast depending on the key distribution).</div></div><div class=""><br class=""></div><div class="">Under what circumstances did gen_event fall short, and what benefits does telemetry offer over it? Is this for many, many notifications for each event, or for many, many different event types? I can see how gen_event can get clogged up with many pending callbacks, whereas telemetry relies on the concurrency of the existing processes. So maybe backpressure is the biggest benefit overall.</div><div class=""><br class=""></div><div class="">jay</div><div class=""><br class=""></div></body></html>