2

I'm currently in a project making a gameserver. Every player is supposed have an own process with gen_fsm behavior. To start gen_fsm with start/3 we need a unique atom, currently we use make_ref() and have found a way to make this ref into an atom with ref_to_list/1. But according to this post it is not recommended and I agree with him.

How would you solve this problem? When we start a gen_fsm with the local option we need an atom to identify it.

softarn
  • 5,327
  • 3
  • 40
  • 54

3 Answers3

7

If you use gen_fsm:start/3 the only atom you need is the callback module name. That way you only have to keep track of a PID (process ID) which will automatically be unique.

If you need to reach the gen_fsm process later, either save the PID in some sort of mapping table or name the process (as you did).

Adam Lindberg
  • 16,447
  • 6
  • 65
  • 85
  • 1
    Thank you, I missed the fact that FsmRef could also be a Pid when using the gen_fsm:send_event/2, thought i needed an atom... thinking of it, that wouldn't make any sense. – softarn May 03 '11 at 09:06
2

Maybe I'm missing something, but it sounds like your best course of action would be to not specify the local option, i.e. to not give the gen_fsm process a name.

It's worth noting that there is a limit to the number of unique atoms that an instance of the erlang vm can use. So generating lots of random atoms is probably a bad idea.

mpm
  • 1,066
  • 9
  • 23
0

You should see gproc (https://github.com/esl/gproc) to create process registry for associating some erlang term with pid() of process. It is not good idea to register each started gen_fsm process with unique atom.

Maxim 'Zert' Treskin
  • 340
  • 1
  • 7