2

let's say you want to populate an erlang node with 100 non registered gen_fsm representing dogs. Each dog can move around, and must be able to forward to some central process its current position. Other processes, (for example a dogcatcher) should ask to the central process if some dog is nearby him.

Now the question is: storing in the state of the central process a list of tuples in the form {Pid, {X,Y}} is a good solution? And if so, can the only central process be a bottleneck?

user601836
  • 3,215
  • 4
  • 38
  • 48

3 Answers3

3

For a readymade robust solution to a flexible process registry have a look at gproc

Peer Stritzinger
  • 8,232
  • 2
  • 30
  • 43
2

I have faced the similar problem also for autodispatching great amount of clients and servers. 1.1. Maybe proecess group pg2 module can provide some help, It contain the following functions:

get_closest_pid(Name) -> pid() | {error, Reason}
get_members(Name) -> [pid()] | {error, {no_such_group, Name}}

1.2. Maybe you could divide the whole space into smaller region, and every region has accepted size and just the region leader contains the information.

Chen Yu
  • 3,955
  • 1
  • 24
  • 51
1

Anything Process acting as Central Man in an application, presents a bottle neck. Whenever i encounter such a scenario, i involve ETS Tables. First consider this Question and its Answer. Usually, this kind of storage will allow proper and robust access to data structures within an Erlang application. Without ETS Tables, your application may not go beyond a certain length of a List or an Array or set e.t.c. in which you are storing Pids.

Besides, the Central process may die and the entire state is lost. ETS tables provide a way of handling the situation when the table owner crashes, the table can actually be handed over to another process in range. The List or Array in the application process may grow in length or size at which searching, looking up and/or deleting from it, may be very memory consuming procedures. Save yourself from stress, look into ETS Tables, and all that has got to do with them, and you will be up to speed in a few minutes (or hours depending on the complexity of your task).

Community
  • 1
  • 1
Muzaaya Joshua
  • 7,736
  • 3
  • 47
  • 86
  • One problem with this is that the ETS table also can become a bottleneck, especially on systems with many cores where processes will vie with each other for access to the table. – rvirding Feb 21 '12 at 23:38
  • true, but it does not normally happen in many applications. This is because not so many apps are heavilly concurrent to a level of crashing an `ETS` Table. If it cannot handle the concurrency, `mnesia_tm` , i mean, `mnesia RAM tables` set in – Muzaaya Joshua Feb 22 '12 at 06:47