[erlang-questions] Telemetry v0.3.0

[Jay Nelson]

I’m curious how this is different from gen_event (http://erlang.org/doc/man/gen_event.html <http://erlang.org/doc/man/gen_event.html>) 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.

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).

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.

jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190101/cedebdb9/attachment.htm>