Concatenating atoms

[Thomas Lindgren]

--- Valentin Micic <valentin@REDACTED> wrote:

> Isn't a situatuion that you're describing an anomaly
> rather than a rule? It
> is not so easy to find a system that needs more than
> 1,000,000 constants.

It depends (see also the end of this message :-). 

The difficulty is, it's not 1M (or whatever) atoms at
a single time, but 1M over the history of the live
node.

> > If you want to be sure never to create new atoms,
> you
> > need to be careful about:
...
> > - using third party utilities that can create new
> > atoms (e.g., file:consult and friends)
> or XMERL... granted. I normally put this kind of
> code on a separate
> run-time. So if I want to parse XML encoded L.N
> Tolstoy's WAR & PEACE it may
> crash without affecting the core (i.e. uranium fuel
> rods).

Good point. This is a useful technique for containing
other resource disasters, e.g., running out of memory.
(Per Bergqvist pointed that out to me :-) In this
case, you also have to be careful about what atoms you
send to the "uncontaminated" node.

> > - creating new named ets or mnesia tables
> I don't know... that is a lot of named ets or mnesia
> tables. 

Well, the point is, it all adds up. Or might add up.

> [ets tables, registered processes, etc deleted]
> > - contacting new nodes
> Hmmm... streching it a bit?

Depends on your system. What if you have some crazy
P2P scenario? What if you want to run for a really
long time?

> > - loading new modules (module names are atoms)
> > - loading new versions of old modules with new
> > exported function names (more atoms)
> 
> Let's be serious. Why would you want to GC these
> things in a frist place?

If you load a module with a new export, you can do
apply on it; that means you need a new atom in the
atom table. Likewise for new modules.

Sure, most of these examples (parsing apart) probably
won't gobble up the atom table in a hurry. If you want
to be SURE, you still have to think about it. But
wouldn't it be better not to have to worry about the
issue at all?

> /.../ Is it worth it?

Yeah, that's the key question ... In my opinion, it's
an implementation flaw, and should (at least
eventually) be fixed. To be fair, as mentioned before,
a lot of systems seem to manage without it. 

> Wouldn't it be easier to introduce a flag that may
> decrease/increase the
> size of atom table to some custom value, provided
> that that flag does not
> exist already.

In general, I'd say that only delays the inevitable
:-) (I thought there was such a flag, but I can't seem
to find it.)

If you don't care (short-running program, or willing
to reboot every now and then, or node restarted often
enough for it not to practically matter, or whatever)
or know/guarantee/require that you have a bounded
"working set" of atoms over the lifetime of the node,
then yes: that is enough. Otherwise, no.

Best,
Thomas



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250