[erlang-questions] erl_tracer, trace_status and pids

[Lukas Larsson]

Hello,

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
>

yes


> * 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. (
http://erlang.org/documentation/doc-9.0-rc1/erts-9.0/doc/html/erl_nif.html#enif_hash
)

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