Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

[Ulf Wiger]

On Fri, 16 Mar 2001, Chris Pressey wrote:

>Alexander Williams wrote:
>
>I totally agree.  However, I can't think of a way to stop people from
>writing 'bot code like:
>
>  apply(unix, cmd, ["rm -rf *"]).

For various other reasons, it would be nice if it were possible to
trap all calls coming out from a module, but one such reason would be
safety.

I've had a few ideas:

- if code runs in another node, one might want to specialize the RPC
  behaviour. Then, in fact making RPC a behaviour would be very handy.
  One could perhaps specify at Erlang boot time via a kernel
  environment variable which behaviour module to use for rpc.
  When you think about it, lots more modules in OTP should really 
  be behaviours that could be specialized.

- We've played around with different ways of taking care of really
  hairy upgrade scenarios. One idea that came up (I think OTP is 
  still thinking about whether to cheer or throw eggs at us) was 
  to make it possible via the OTP R7B trace mechanism to reroute
  a function call to another function (with same arity). For example
  all calls to mnesia:write/1 could be rerouted to myMnesia:write/2;
  a corresponding trap for message sending could be to call
  M:F(Pid, Message) instead of sending the message. Dangerous stuff,
  but it would be extremely flexible.


>My feelings - though I'm a mnesia newbie - is that one big table (in
>RAM) is going to be the fastest solution - because any partitioning
>would mean more resource-accesses per data-access.  I don't see a lot of
>reason to add filesystem directories to the mix, as mnesia already has
>many of the properties that files have but database fields traditionally
>do not (variable length, complex structures etc.)

It really depends on just how big your big table is. If it's in the
neighbourhood of a million objects, you probably don't want to use
mnesia. Performance will be great as soon as you have the data in RAM,
but it will take many hours to load it from dets -- days if the file
needs repair. I ran into just that problem with CCviewer: a table with
2 million objects took 36 hours to load, so I resorted to a file
system database instead. 

The situation should be much improved in OTP R8, I've been told.

>There are also some 'higher-order sense' that turn out to be useful. 
>For example, being able to see someone else move.  {see_move, Sender,
>NewPosition} or something.

Have you read the thesis on OTP behaviours for simulations?
I don't remember the URL, but it was posted on this list recently.


/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB