Apologies & explanation
G Bulmer
I was intending to spend a couple of intensive weeks working on Erlang-
DTrace. I have been tied up trying to make a living for months, but I
had hoped to release source last weekend (before EUC).
A few weeks ago I got involved in a project even nearer to my heart
than Erlang-DTrace (ask me if you are at EUC, and have plenty of
time :-)!
I've had only a couple of days on Erlang-DTrace, so I am, at best,
more than a week of solid work away.
I have held back on releasing code because it is ugly, and I am
changing all of the DTrace interface.
Firstly, the existing code is tightly intertwined with the Erlang
source for R12B-1, and I've been teasing it apart to apply to to newer
releases.
Secondly, the current DTrace API only works well for a single VM. The
existing DTrace interfaces only works for local process IDs, and they
are passed 'raw'.
My aim is to enable an Erlang-DTrace script to monitor a cluster of
Erlang Nodes, and track Erlang processes across the cluster.
This isn't yet critical (for the current Erlang-DTrace interface), but
we'll need it to track send and receive, so I am laying some of the
ground work first.
Process IDs for processes within the local Erlang Node are numbers (28
bits) in a tagged value (think lisp for dynamic tagged types), and
that whole thing, including tag is currently passed to Erlang-DTrace.
Process IDs for 'foreign' processes are local process IDs + an atom
which is the name of the foreign Erlang Node (e.g. 'fred@bigmachine').
I have been working on a more general Process ID (PID) mechanism.
The latest approach is to simply pass the numeric part of the PID
(with the PID tag removed), *plus* the Erlang Node-name atom string.
When their is no Node name, because it is a standalone VM, it's value
is set by the Erlang VM anyway (to noname@nohost).
When the Node has a name, that atom will be passed to Erlang-DTrace too.
Anyway, apologies to all. I will get a few days later this month, so I
hope to release end of November/early December.
Thanks for everyone's forbearance.
GB
Tim
> Erlang Nodes, and track Erlang processes across the cluster.
> The latest approach is to simply pass the numeric part of the PID
> (with the PID tag removed), *plus* the Erlang Node-name atom string.
provided what you want? The operating system pid should correlate one-
to-one with the node-name...
> A few weeks ago I got involved in a project even nearer to my heart
> than Erlang-DTrace (ask me if you are at EUC, and have plenty of
> time :-)!
"sold-out". Which unfortunately means that I'll be missing you're talk
as well. Let me know if there's anything I can help with in terms of
preparation or preparations for a release, I'm looking forward to see
some code!
-tim
G Bulmer
>
>> My aim is to enable an Erlang-DTrace script to monitor a cluster of
>> Erlang Nodes, and track Erlang processes across the cluster.
>
>> I have been working on a more general Process ID (PID) mechanism.
>> The latest approach is to simply pass the numeric part of the PID
>> (with the PID tag removed), *plus* the Erlang Node-name atom string.
>
> Doesn't the build-in dtrace pid variable (the operating system pid)
> provided what you want? The operating system pid should correlate one-
> to-one with the node-name...
I agree an OS process ID + Erlang PID is fine when the Erlang process
is within that OS process.
In those case, the local PID + OS process id is unique, and sufficient.
But let's considers example where the Erlang process isn't local to
the OS process (Erlang Node), but is instead a reference to an Erlang
process in a different Erlang Node. The Erlang PID references an
external PID.
A concrete example is binding a name to an Erlang process in a
different Node (an external process) using register().
Three processes could bind 'foo' to an external process, but the
process ID and Erlang-Node OS-process-id of the Erlang Node doing the
binding doesn't identify the Erlang Node containing the process being
register()'ed.
This is irrelevant for probes that instrument functionality which only
acts on processes within the local Erlang Node, a good example is
garbage collection which only acts on Erlang Processes within the
Erlang Node that triggers the probe [nothing surprising there:-]
But register(), and unregister() are cases where the Erlang Process
may be in a different Erlang Node, and I felt the probe shluld give
enough information to correlate across many Erlang Nodes (this
behaviour may also help spot bugs).
Where I feel it gets important is in send (!), where a cluster-wide
process id should enable DTrace scripts to correlate across send (!)
and receive across the whole cluster.
Does that make sense? Maybe I should create a few pictures because it
*seems* clear when I sketch a situation.
>
>
>
>> A few weeks ago I got involved in a project even nearer to my heart
>> than Erlang-DTrace (ask me if you are at EUC, and have plenty of
>> time :-)!
>
> Sounds interesting!
(I am working with one other guy to design a microcontroller board,
and write prototype software, for something very fun by Christmas)
> Unfortunately, I won't make it to EUC, as it's
> "sold-out".
Pooh!
> Which unfortunately means that I'll be missing you're talk as well.
We may need a third party judge for that one :-)
> Let me know if there's anything I can help with in terms of
> preparation or preparations for a release, I'm looking forward to see
> some code!
I will try to make some progress each week, so I will try to send you
the little prototypes and test cases that I am building. I am building
those because it is easier than dealing with the whole Erlang source,
and I want to see what the DTrace interface looks like, and how it
might be used.
I will need also some help when it settles back down, my release
guru :-)
Take care
GB