[erlang-questions] erl_tracer, trace_status and pids

Lukas Larsson lukas@REDACTED
Mon May 29 13:26:57 CEST 2017


On Fri, May 26, 2017 at 2:41 PM, Loïc Hoguin <essen@REDACTED> wrote:

> * trace_status is always called on enabled/3, not on enabled_*/3


> * when you use enabled_*/3 and trace_*/5 functions for everything, the
> trace/5 function will never be called
hmm, that should be true in the current implementation. That may change in
the future though.

> * trace_status is always called before any other enabled_*/3 so I should
> be fine just doing nothing in enabled_*/3, right? I'm only checking that
> the tracer processes are still alive anyway.

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.

> Basically if you could shed light on the circumstances around trace_status
> that would help a lot for optimizing this. :-)

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.

Another question, I have a pool of tracer processes and want to send the
> events to one of them depending on the pid (all events of a pid gets to the
> same tracer process). Is this a valid solution?
> nth = (tracee.pid >> 4) % len;
> This gives me the number of the tracer I will send the message to.

It is one way to do it, but you are relying on the internal representation
of a PID, which may change, and I don't think you get a very good hash.

In OTP-20 there is a new nif called enif_hash/3 that can be used to get a
better hash value. (

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

More information about the erlang-questions mailing list