<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 30, 2017 at 11:40 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/30/2017 10:14 AM, Loïc Hoguin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* trace_status is always called before any other enabled_*/3 so I<br>
should be fine just doing nothing in enabled_*/3, right? I'm only<br>
checking that the tracer processes are still alive anyway.<br>
<br>
<br>
no, trace_status is not always called before enabled_*. The only event that I know of where it is called is enabled_call/3, there may be a couple of more but not all of them.<br>
</blockquote>
<br>
Alright. I'm a bit confused still. Would it make sense to only perform some checks for trace_status, for example checking that the tracer process exists? Then for other enabled_*/3 calls I would just reject events I don't need.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Basically if you could shed light on the circumstances around<br>
trace_status that would help a lot for optimizing this. :-)<br>
<br>
<br>
the check for trace_status call is made in various places in the vm code where the VM finds it convenient to do a check and see if the tracer is still alive. There are no specific rules about when it is called.<br>
</blockquote>
<br>
It sounds like the answer to my question is a yes. :-)<br>
</blockquote>
<br></span>
Answering myself.<br>
<br>
I think what I was looking for can be found in this sentence of the documentation:<br>
<br>
"It is called in multiple scenarios, but most significantly it is used when tracing is started using this tracer."<br>
<br>
If correct, then this means trace_status is always called at least once before anything happens; and that's good enough for me. That would allow me to remove traces for the tracer processes immediately when receiving the trace_status, and not have to worry about that in enabled_*/3 calls.<br></blockquote><div><br></div><div>It is not overly clear/correct in the docs. One purpose of trace_status was that it and only it should be able to remove tracers from the tracee. There are assertions in the code that prohibit trace nifs from returning 'remove' from any event other then trace_status. However, those are only triggered in debug builds. The current non-debug code and to some extent docs seems to allow enabled_*/3 calls to also remove tracers from tracees.</div><div><br></div><div>Writing clear and concise documentation is hard.</div><div><br></div><div>Lukas</div></div></div></div>