Was Mapping processes Now: ATOMS and atom_tab index

[Valentin]

I agree that PID can be used to uniquely identify processes, and that works
very well if the application completely lives in ERLANG and/or one part
lives in ERLANG (i.e. server) and another in some other environment (i.e.
CNode). However, if one wants to use ERLANG as a middleware product (for
example, to do the similar thing as VITRIA or TIBCO for a fraction of the
cost), it has to figure out the best way to establish a short-lived
connections between processes that live outside ERLANG (i.e. using ERLANG as
a value-added broker -- implement common functions like authorization, usage
recording, statistics, etc). As a common integration point, ERLANG really
has to offer much more than any other platform I've seen so far.

Valentin.


----- Original Message -----
From: "Chandrashekhar Mullaparthi"
<Chandrashekhar.Mullaparthi@REDACTED>
To: "'Valentin'" <valentin@REDACTED>; <erlang-questions@REDACTED>
Sent: Thursday, December 19, 2002 3:50 AM
Subject: RE: Was Mapping processes Now: ATOMS and atom_tab index


> Using global will create problems if you have more than one erlang node in
a
> mesh, all doing pretty much the same thing. And every call to
> global:register_name, global:re_register_name, global:unregister_name
makes
> a synchronous call to every node in the mesh.
>
> The PID of a process is unique within the node - I usually associate a
name
> to a process only when it is going to live a long time or when it should
be
> seen across a network of nodes. Why do you need this for such short-lived
> processes? As Luke said in the previous thread, the PID can be used as or
as
> part of the request-id?
>
> The limitation is documented. See
> http://www.erlang.org/doc/r9b/doc/efficiency_guide/advanced.html#7.2
>
> Chandru
>
> -----Original Message-----
> From: Valentin [mailto:valentin@REDACTED]
> Sent: 18 December 2002 19:48
> To: erlang-questions@REDACTED
> Subject: Fw: Was Mapping processes Now: ATOMS and atom_tab index
>
>
>
>  We have discovered (the hard way) that number of atoms in ERTS is limited
> to
>  1024*1024, which limits the number of atoms to 1,048,576. The question
was
>  posted recently asking how to increase this limit, but judging from the
> lack
>  of response, I guess, there isn't one. We have found the code where this
>  table was allocated, but I do not think that the recompilation with
changed
>  value will do any good, as it might have side effects.
>
>  When the space in the atom_tab index is reached,  erlang crashes with the
>  bang. And quite a sizable dump.
>  It might be a good idea to mention this limitation somewhere in the
manual
>  (hopefully in ei_x_encode_atom(...) description as well).
>
>  Eduardo, as well as Martin before him, had a good idea (that is, if you
ask
>  me). It seems odd that one has to use ets, or similar mechanism to
register
>  a short-lived processes, if such a mechanism already exist, but cannot be
>  used because it requires an atom, as an argument.
>
>  On the other hand, I've noticed that global:register_name/2 supports
string
>  as registration name argument as well. I wonder, would it be wise to use
>  this in a context that Eduardo was describing, by using
>  global:register_name/2 and global:whereis_name/1.
>
>  What would be the catch (other than specific syntax that has to be used
in
>  order to send a message?) Any performance penalty?
>
>  Valentin.
>
> >
> > ----- Original Message -----
> > From: "martin j logan" <martin@REDACTED>
> > To: <eduardo@REDACTED>
> > Cc: <erlang-questions@REDACTED>
> > Sent: Wednesday, December 18, 2002 12:26 AM
> > Subject: Re: Mapping processes
> >
> >
> > > Eduardo,
> > >    When I first started using erlang I also had this idea.  I went so
> > > far as to implement it. I spent about an hour trying to figure out
what
> > > clever construct I had come up with in order to fool the garbage
> > > collector so completely and cause such a nasty "memory leak". The
thing
> > > is that the first argument to register must be an atom so you must
> > > convert reqID to an atom. I found out after a bit of research that
atoms
> > > are not garbage collected, they are stored in a table for the life of
> > > the system. So in the interest of helping a fellow erlanger avoid such
> > > folly as I engaged in let me say that you should not ever dynamically
> > > create atoms in any situation that is not garaunteed to be finite. I
> > > typically use an ets table, loop data/dict, or some such to store
> > > mappings. This is coupled with some facility to remove the processes
> > > when they die. In this manner you can nicely achieve the same
> > > functionality.
> > >
> > > Cheers,
> > > Martin
> > >
> > > On Tue, 2002-12-17 at 13:50, Vladimir Sekissov wrote:
> > > > Good day,
> > > >
> > > > eduardo> What do you think about using register(reqId, PID) and
> > > > eduardo> whereis(reqId) to
> > > > eduardo> retrieve the PID so to send the response, in an async. way,
> > > > eduardo> to the calling process.
> > > >
> > > > I think you could easily exceed the atoms table limit on long living
> > > > system. Using simple dictionary of {callerPid, reqId} and trapping
> > > > exit messages from callers to delete records from dictionary would
be
> > > > better solution. May be like this or as gen_server:
> > > >
> > > > create_dict() ->
> > > >   spawn_link(fun dict_srv/0).
> > > >
> > > > remove_dict(DPid) ->
> > > >   DPid ! {self(), stop},
> > > >   receive
> > > >     {DPid, stopped} ->
> > > >       ok
> > > >   end.
> > > >
> > > > dict_add(DPid, Pid, Reg) ->
> > > >   DPid ! {self(), add, {Pid, Reg}}.
> > > >
> > > > dict_get(DPid, Reg) ->
> > > >   DPid ! {self(), get, Reg},
> > > >   receive
> > > >     {DPid, {value, {Pid, _}}} ->
> > > >       Pid;
> > > >     {DPid, false} ->
> > > >       undefined
> > > >   end.
> > > >
> > > > dict_srv() ->
> > > >   process_flag(trap_exit, true),
> > > >   dict_loop([]).
> > > >
> > > > dict_loop(Dict) ->
> > > >   receive
> > > >     {_From, add, V={Pid, Reg}} ->
> > > >       link(Pid),
> > > >       dict_loop([V|Dict]);
> > > >     {From, get, Reg} ->
> > > >       From ! {self(), lists:keysearch(Reg, 2, Dict)},
> > > >       dict_loop(Dict);
> > > >     {'EXIT', Pid, Reson} ->
> > > >       case lists:keymember(Pid, 1, Dict) of
> > > > true ->
> > > >   dict_loop(lists:keydelete(Pid, 1, Dict));
> > > > false ->
> > > >   exit(Reson)
> > > >       end;
> > > >     {From, stop} ->
> > > >       From ! {self(), stopped},
> > > >       ok
> > > >   end.
> > > >
> > > > Best Regards,
> > > > Vladimir Sekissov
> > > >
> > > > eduardo>
> > > > eduardo> I'm thinking how to map processes with request Id so to
> manage
> > > > eduardo> callbacks when using ports.
> > > > eduardo> What do you think about using register(reqId, PID) and
> > whereis(reqId) to
> > > > eduardo> retrieve the PID so to send the response, in an async. way,
> to
> > the calling process.
> > > > eduardo>
> > > > eduardo>
> > > > eduardo>
> > > > eduardo> Thanks,
> > > > eduardo> Eduardo Figoli
> > > > eduardo> INSwitch Solutions
> > > > eduardo>
> > > > eduardo>
> > > > eduardo>
> > > > eduardo>
> > >
> > >
> >
>
>
>
> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential.  If you have received
> this email in error please notify the sender immediately and delete this
> email from your system without copying or disseminating it or placing any
> reliance upon its contents.  We cannot accept liability for any breaches
of
> confidence arising through use of email.  Any opinions expressed in this
> email (including attachments) are those of the author and do not
necessarily
> reflect our opinions.  We will not accept responsibility for any
commitments
> made by our employees outside the scope of our business.  We do not
warrant
> the accuracy or completeness of such information.
>