Fri Feb 4 11:57:38 CET 2005
--- 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
> > If you want to be sure never to create new atoms,
> > 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
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
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
> > - 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.
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
More information about the erlang-questions