[erlang-questions] Trace-Driven Development

[Ulf Wiger]

On 6 Jun 2012, at 07:05, Michael Turner wrote:

> Ulf, I misinterpreted this:
> 
>> The seq_trace system_tracer allows only one [tracer (process)] per node.
>> 
>> A generic lamport clock implementation has no need for
>> such limitations.
> 
> I read this as claiming that seq_trace tracing is limited to a node,
> which is (now, after a good night's sleep) rather obviously an
> overstretched interpretation, at best.

In Erlang/OTP parlance, the tracer is a process that receives the 
trace output generated when tracing is enabled. In the normal
trace support, you can have 0 or 1 tracers per process. The trace
messages generated can very well be the result of messages
received from, or sent to, other nodes.

In order to collect and merge trace output, you can use ttb.
TTB interfaces with 'dbg', and both (as well as 'et') are able to 
process seq_trace output.

TTB does have some utility functions to help with sequence
tracing, but when it merges trace output, it only looks at the 
timestamp (even for seq_trace output).

Since seq_trace tokens are passed to the receiving process
in a message send, it has to work across nodes, but the *trace
output*, for both sequence trace and normal trace, is only
emitted to the respective local tracer(s) on each node.

(The trace BIFs can also use an IP port or file descriptor
as a tracer, but the principle is the same).

> That said, however, the seq_trace documentation seems to say
> conflicting things on this point, and I assumed you were working from
> where it says this:
> 
> "The system tracer will only receive those trace events that occur
> locally within the Erlang node. To get the whole picture of a
> sequential trace that involves processes on several Erlang nodes, the
> output from the system tracer on each involved node must be merged
> (off line)."

There are two levels to seq_trace:

- the exchanging of tokens to maintain the counters
- the collection of possibly emitted trace data

The former works across nodes. The latter assumes the presence
of some multi-node collector and merge function. OTP offers ttb,
which handles seq_trace output, but not completely (see above).

The thing about seq_trace that is slightly different from normal trace
is that it invites the active cooperation of the processes themselves
(e.g. calling functions like seq_trace:print() and seq_trace:set_token()).

The "infection process" works transparently, once initiated. It can
also be initiated through trace patterns, making it entirely 
transparent to the processes being traced.

Actually, I have on several occasions raised the suggestion that
there should be a function to emit a trace event from within the 
code. Today, that's normally done by calling some empty function
(which is also how 'et' does it). For some reason, I - and apparently
others - have overlooked that seq_trace in fact has such a function.

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com