addressing a lot of processes

[Sean Hinde]

On 21 May 2005, at 13:02, Gaspar Chilingarov wrote:

> Matthias Lang wrote:
>
>>  > On 20 May 2005, at 16:23, Gaspar Chilingarov wrote:
>>  > > For now, I've implemented sample manager, which maps IP 
>> (string) to PID
>>  > > using gb_trees. In another hand, I've seen sample in some erlang
>>  > > sources, to register process under unique name say ip_127.0.0.1,
>>  > > ip_127.0.0.2 etc.
>>  > >
>>  > > This leads to generating the new atoms in runtime, and I'm  
>> conscious  > > that erlang's GC will not clean them if they are  
>> unused. Am I right?
>> IP(string) and IP(atom) aren't the only representations. In this  
>> case,
>> IP(tuple) would also make sense, and the conversion is easy:
>>   {ok, Tuple} = inet:getaddr(String, inet)
>> IP(integer) is another possibility, i.e.
>>   {ok, {A,B,C,D}} = inet:getaddr(String, inet),
>>   Integer = (A bsl 24) + (B bsl 16) + (C bsl 8) + D.
>> Then you don't have to worry about the atom table _and_ you have a
>> useful representation.
>> Matthias
>>
>
>
> in case if I use atoms I can write smthing like this
>
> try
>     ip_127_0_0_1  ! { processNewData, SomeData }
> catch
>     Any ->
>      createAndRegisterNewProcess(127_0_0_1)
>         ip_127_0_0_1  ! { processNewData, SomeData }
> end
>
>
> This will perform lookup not in Erlang data structure - gb_tree in  
> my case, but in erlangs internal table, which should be faster.
> In case that ~ have limited set of ip's which should be processed,  
> I think I can avoid trashing of atoms table.
>

One common solution is to maintain a named protected ets table of IP  
Addr -> Pid. Looking up in an ets table is pretty much the same as  
looking up in an "erlang internal table", and the calling process can  
do it directly:

case ets:lookup(mapper, {127,0,0,1}) of
     [{_, Pid}] ->
         Pid ! { processNewData, SomeData };
     [] ->
         Pid = createAndRegisterNewProcess({127,0,0,1}),   %% This  
should make a call to the ets table owning process to insert the new  
entry
         Pid ! { processNewData, SomeData }
end

OTOH if you know you will have a bounded set of IP addresses then  
your atom scheme is OK also

Sean