[erlang-questions] "actor database" - architectural strategy question
Tue Feb 18 19:26:57 CET 2014
Fred Hebert wrote:
> On 02/18, Miles Fidelman wrote:
>> For scaling, the next step would be to swap out to disk - if that happens as
>> a hibernate to disk, all the other functionality would stick around (as
>> opposed to an application level write-state-to-disk). Hence the question
>> re. internals of the hibernate BIF and the scheduler, and how one might
>> think about wiring in a hibernate-to-disk function.
> Be aware of the implicit state that exists within an application:
> pending requests, messages in a mailbox, links and monitors being set
> up, code versions being in use, sockets and file descriptors, etc.
> These things can be backed up, but reloading them does not promise a
> workable process with an equivalent environment upon reloading. You
> either have to write code that can deal with that, or prevent code that
> cannot deal with it from being written.
and Lukas Larsson wrote (in response to the same item):
> If I were to do something like this I would first try to only put the
> heap and referenced off heap binaries to disk. This should be the
> majority of the memory footprint and will allow all process meta data
> (links, monitors, registry etc etc) to remain unaffected. The question
> is what to do about the stack which could contain pointers to code
> that has been changed while the process was hibernated.
Fred: Are you suggesting that application state has to be preserved when
hibernating a process today? I may be missing something, but I thought
the point of hibernation was to reduce process footprint transparently.
Lukas: I think that really zeros in on the question.
Anybody know where I should start looking for documentation of the
current hibernation mechanism?
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions