[erlang-questions] erl_tracer, trace_status and pids
Tue May 30 10:14:27 CEST 2017
Thanks for the replies!
On 05/29/2017 01:26 PM, Lukas Larsson wrote:
> * 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.
I'll change it in the future then. :-)
> * 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.
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.
> 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.
It sounds like the answer to my question is a yes. :-)
> 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.
Thanks, I will use it on OTP 20+ then.
More information about the erlang-questions