start phases

Ulf Wiger ulf@REDACTED
Fri Mar 4 12:39:45 CET 2005

Den 2005-03-04 11:57:24 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:

> The drawback, as I recall, is that it can be difficult
> to see why the system refuses to start. Some sort of
> inspection tool, as you suggest, may be necessary.

I found while debugging my prototype that it was
fairly easy to figure out who was waiting for what
by just looking at the dictionary of my

It was sometimes more difficult to debug errors due
to functions being called too early (partly because
if e.g. c:erlangrc() kicks in before the file driver
is ready, you most likely don't have the I/O
subsystem ready either. In later phases, it should be

Another recent hack was a local registry that allowed
for registration of non-unique keys. Essentially, each
process could register any number of unique keys (any
erlang term) and any number of non-unique ones.

In addition, you could fold over the process registry
based on 'select' criteria (using the ets:select()
syntax) and apply some function for each key.

One idea was that you could publish services this way,
perhaps parameterized (e.g. {megaco, LinkId}). Another
idea was that you could use it to group processes in
different categories -- essentially, it becomes a set
indexes through which one can locate functions in the

The final idea was to come up with a way to inspect and
debug processes in huge systems, with several hundred
thousand processes. This seemed to work excellently.

I'm not sure you have to tie these two ideas together,
but I think they both help to simplify specification and
inspection of large systems.


More information about the erlang-questions mailing list