[erlang-questions] "actor database" - architectural strategy question

[Miles Fidelman]

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.
<snip>

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?

Thanks,

Miles




-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra