崩溃后如何恢复进程状态?

发布于 2024-07-19 15:02:28 字数 345 浏览 6 评论 0原文

重新启动崩溃的进程时保持状态的好方法是什么?

我在 OTP 应用程序中有一个主管,负责监视几个“子系统”gen_servers。

例如,一个是“天气”子系统,它每 15 分钟生成一个新的天气状态并处理对当前天气状态的查询。 (想想柠檬水摊游戏)

如果 gen_server 崩溃了,我希望它重新启动,但它应该以最近的天气状态重新启动,而不是在 init() 中硬编码的某些任意状态。 仅仅因为坠机事故,模拟状态突然从“冰雹风暴”变成“微风徐徐”是没有意义的。

我犹豫是否使用 mnesia 或 ETS 在每次更新后存储状态,因为增加了复杂性; 有更容易的方法吗?

What's a good way to persist state when restarting a crashed process?

I have a supervisor in an OTP application what watches several "subsystem" gen_servers.

For example, one is a "weather" subsystem that generates a new weather state every 15 minutes and handles queries for the current state of the weather. (Think the lemonade stand game)

If that gen_server crashes, I want it to be restarted, but it should be be restarted with the most recent weather state, not some arbitrary state hardcoded in init(). It wouldn't make sense for the simulation state to suddenly go from "hail storm" to "pleasant and breezy" just because of the crash.

I hesitate to use mnesia or ETS to store the state after every update because of the added complexity; is there an easier way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

遇见了你 2024-07-26 15:02:29

有没有更简单的方法?

当进程死亡时,它会向主管发送包含进程状态的消息,因此您可以使用此值存储在主管中(在 mnesia 或主管状态中),并且当您的服务器启动时(在 init 中),它具有向主管发送同步调用以获取状态值。 我没有真正的例子,但我希望这是有道理的。

无论如何,我真的没有看到在 mnesia 中存储状态的问题。

对不起我的英语:)

is there an easier way?

when process died it sends message to supervisor that containing State of process, so you can use this value to store in supervisor (in mnesia or supervisor's state) and when your server will start (in init) it have to send sync call to supervisor to get State value. I haven't real example, but i hope it makes sense.

Anyway i don't really see problem to store State in mnesia.

sorry my English :)

好听的两个字的网名 2024-07-26 15:02:28

只要是在运行时,就会建议使用 ETS。 价值远远大于复杂性。 API 很简单,如果您使用命名表,访问也很简单。 您只需在主管启动 gen_server 之前创建该表。

两种更复杂的替代方案:

  • 构建一对进程,一个用于执行工作,一个用于状态维护。 由于第二个的简单性,它非常可靠。
  • 真正愚蠢的可能是每次状态发生变化时,将主管的子规范与当前状态作为参数进行交换。 (微笑)不,只是开玩笑。

As long as it just has to be during runtime a would suggest the usage of ETS. The value is by far greater than the complexity. The API is simple and if you're working with named tables the access is simple too. You only have to create the table before your gen_server is started by the supervisor.

Two - more complex - alternatives:

  • Build a pair of processes, one for the job to do, one for the state maintenance. Due to the simplicity of the second one it would be really reliable.
  • A real silly one could be the exchange of the child spec of the supervisor with the current state as argument each time the state is changing. (smile) No, just kidding.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文