
<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>The plan for detaching on failure is to trigger an event that can be handled.<br></div><div><br></div><div>It is for many different event types. Maybe some of those will be handled by something that makes use of gen_event to manage the event, but for the general case of essentially hooking into many dynamically defined events it makes more sense to not require them all to be going through another process. The individual handlers themselves can then pass off to a process to serialize through if that handler requires it.<br></div><div><br></div><div>Tristan<br></div><div><br></div><div>On Tue, Jan 1, 2019, at 11:58, Jay Nelson wrote:<br></div><blockquote type="cite" id="fastmail-quoted"><div>I’m curious how this is different from gen_event (<a class="fastmail-quoted-" href="http://erlang.org/doc/man/gen_event.html">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.<br></div><div class="fastmail-quoted-"><div class="fastmail-quoted-"><br></div><div class="fastmail-quoted-">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).<br></div></div><div class="fastmail-quoted-"><br></div><div class="fastmail-quoted-">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.<br></div><div class="fastmail-quoted-"><br></div><div class="fastmail-quoted-">jay<br></div><div class="fastmail-quoted-"><br></div><div>_______________________________________________<br></div><div>erlang-questions mailing list<br></div><div>erlang-questions@erlang.org<br></div><div>http://erlang.org/mailman/listinfo/erlang-questions<br></div><div><br></div></blockquote><div><br></div></body></html>