<div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 12:02 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div>On 21 Sep 2015, at 10:52, Lukas Larsson <<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">To start the discussion, here are a few of my ideas in no particular order:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Create a couple of scalable high throughput tracing output backends with different overflow mechanics. Today all tracing is funneled through one bottleneck and has no overflow handling at all.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Expose vm probes (today dtrace probes) to the erlang tracer.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Allow the erlang tracer to be an Erlang callback module. Today only ports/processes are allowed.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Optimize trace output to file/ip. Maybe use something like the Common Trace Format (<a href="http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master" target="_blank">http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master</a>), instead of the term_to_binary that we have today.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Write much much better documentation for dbg :)</div></div></blockquote><br></div></span><div>+1 on the suggestions, esp. multiple tracers. The one-tracer restriction makes it hard to explore some very interesting monitoring and debugging ideas.</div></div></blockquote><div><br></div><div>Those are very good starting points. </div><div><br></div><div>For multiple tracers, I would assume that they will be independent - i.e. not all of them get all tracing events, but only the ones they are interested in. The question is if the tracing engine can be made fast enough, possibly only if the filtering criteria are restricted to term matching (as opposed to arbitrary predicates provided by users). </div><div><br></div><div>Also, it might be interesting to consider having the configuration in a declarative format that is easier to understand and maintain, while also allowing to keep the configuration separate from the code (in an external file). It's not difficult to implement that on top the current API, but a common and official format would feel a lot better.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>One might fantasize about enabling migration from io:format() debugging to this, ideally by simply rewriting the debug macro: a handy wrapper that simulates the original printouts. There are some problems with this, so I’ve chosen not to go there.</div></div></blockquote><div><br></div><div>Ulf, could you please sketch the issues that you encountered?</div><div> </div><div>best regards,</div><div>Vlad</div><div><br></div></div></div></div>