Erlang 中 gen_fsm:start/3 的独特原子
我目前正在进行一个制作游戏服务器的项目。每个玩家都应该有一个自己的具有 gen_fsm 行为的进程。要使用 start/3 启动 gen_fsm，我们需要一个唯一的原子，目前我们使用 make_ref() 并找到了一种方法将此 ref 变成具有 ref_to_list/1 的原子。但根据 这篇文章 不建议这样做，我同意他。
你会如何解决这个问题？当我们使用本地选项启动 gen_fsm 时，我们需要一个原子来识别它。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用 gen_fsm:start/3 ，您唯一需要的原子就是回调模块名称。这样，您只需跟踪 PID（进程 ID），该 PID 将自动成为唯一的。
如果您稍后需要访问 gen_fsm 进程，请将 PID 保存在某种映射表中或为该进程命名（就像您所做的那样）。
If you use
gen_fsm:start/3the 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_fsmprocess later, either save the PID in some sort of mapping table or name the process (as you did).也许我错过了一些东西，但听起来你最好的做法是不指定
local选项，即不给 gen_fsm 进程命名。值得注意的是，实例的唯一原子的数量有限制 erlang vm的可以使用。因此，生成大量随机原子可能是一个坏主意。
Maybe I'm missing something, but it sounds like your best course of action would be to not specify the
localoption, 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.
您应该看到 gproc (https://github.com/esl/gproc) 来创建进程注册表，以将某些 erlang 术语与进程的 pid() 相关联。用唯一的原子注册每个启动的 gen_fsm 进程并不是一个好主意。
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.