Snapshot of entire app?

Questions / Help
1

This may be a naive question… Just curious, no real-life need yet.

Suppose I have an app the consists of several long-running processes
as well as perhaps some “ephemeral” processes.

Is it possible/practical somehow to save the entire app state on shutdown
and reload it on restart?

I hate to use the word “state” here… but a running app certainly does
have state in a global sense. :slight_smile:

Hal Fulton

1 Like
2

As far as I’ve ever seen in the Erlang world, no, running process state if you want to serialize it then you need to do it yourself (or via library or so), nothing built-in. The BEAM is not LISP sadly. :slight_smile:

1 Like
3

My question was unclear – as are my thoughts. :wink:

For now, I’ll just withdraw the question.

FYI, chatted a few minutes in slack on this (below).

Thanks,
Hal

david.antaramian [12:10 PM]
@hal9000 I guess that in theory it would be possible, though it would also go against most of BEAM’s philosophy

hal9000 [12:11 PM]
@david.antaramian I see your point - but at the same time, a running app is anything but stateless.
maybe it’s more a matter of saving the BEAM’s state than the app’s…?

david.antaramian [12:13 PM]
Well, the question to me is under what circumstance you would shutdown and reload the application

hal9000 [12:13 PM]
hmm. maybe it’s all running on one box, and we’re going to reboot it?

david.antaramian [12:14 PM]
OK, following that path, will the state still be valid when you reload it?
Is there anything that will be invalid when the state is loaded back in simply from the passage of time

hal9000 [12:15 PM]
I guess in many cases it would not be valid. But in some it might be — e.g., a big 3D rendering job?

di4na [12:15 PM]
All in one box == not OTPish

david.antaramian [12:15 PM]
Well, you wouldn’t be doing that on BEAM anyways :stuck_out_tongue:

di4na [12:15 PM]
Rule one of reliability : you need two computers

david.antaramian [12:16 PM]
But really, the point is you should save the state outside your runtime
And then read it back in in some structured and expected form when you load up a new instance

hal9000 [12:16 PM]
Your points are quite valid. I should learn more about OTP and supervision trees before I start thinking too much about this.
@david.antaramian if i understand you right, that is exactly what i was asking about
i certainly wasn’t wanting to store state inside processes

david.antaramian [12:19 PM]
You asked about saving the entire application state. I’m talking about business level logic using a source of truth

hal9000 [12:19 PM]
ok, i will have to think about the difference
i think i see what you mean, yes

hal9000 [12:21 PM]
i was probably conflating the two somewhat — e.g. i didn’t mean (necessarily) to save the stack pointer — unless we did actually snapshot the BEAM — which sounds dumber the more I think about it.

1 Like