[erlang-questions] object vs. actor (Re: Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????)

[Miles Fidelman]

Garrett,

Garrett Smith wrote:
> Erlang processes aren't persisted, but their state can be, quite easily.
>
> If the "business logic" associated with your entities/documents is
> expected to change so often that you want to store it as a part of the
> document itself, Erlang offers some excellent options.
>
> A trivial example, in an Erlang shell:
>
> 1>  Add = fun(X, Y) ->  X + Y end.
> 2>  Add(10, 10).
> 100
> 3>  file:write_file("addfun", term_to_binary(Add)).
> 4>  init:stop().
>
> And restart Erlang shell:
>
> 1>  {ok, Bin} = file:read_file("addfun").
> 2>  Add = binary_to_term(Bin).
> 3>  Add(10, 10).
> 100

That's not persisting a process' state, though.  It's not so easy to say:
1. spawn, say, 10,000 gen_fsms,
2. run for a while
3. save the internal state of those 10,000 state machines
4. stop the shell (really the VM)
5. restart
6. restore those state machines, complete with their original PIDs

Fairly straightforward to:

1. spawn 10,000 gen_fsms
2. add their PIDs to a name-to-PID lookup table
3. include logic such that an inactive fsm
- times out
- writes it's state to a file
- updates the name-to-PID table to point the file
- kill itself
4. write a listener that takes incoming messages, identifies the 
associated fsm by name and either
- passes the message to the file, or
- loads and restarts the process, then passes the messages

What I've really done is rewrite erlang's hibernation functionality.
> You don't need CouchDB here -- just store your "logic" off in the
> database of your choice -- or as a base64 encoded blob in your
> document!

CouchDB provides a lot of baseline functionality that I'd just as soon 
not re-write.
>> Our application will be distributing HTML+Javascript documents by email -
>> message like, but also object-like and actor like when live in a client or
>> browser.  The question is how to maintain the actor-like behavior when
>> filing away large numbers of emails.
>>
>> It would be interesting to simply store each message as an erlang thread,
>> accessed through message passing.  But that doesn't scale with current
>> technology.  The short term answer is clearly to use a database of some
>> sort, but a longer solution would be to find ways to support large numbers
>> of hibernating processes.
>>
>>> You can even call them "objects" and the VM will work just the same :)
>>>
>> I could call them that, but erlang does NOT support object-oriented
>> programming in the sense of inheritance and so forth.
> If you're planning to store "code" with these documents, using
> side-effect free functions is a Very Good Idea, IMO.
Well sure!

> Btw, off topic, but this is an interesting take on OO (note the author):
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

It is.  As I understand it, Kay originally envisioned Smalltalk objects 
as more "actor-like" (i.e., each running as an independent process or 
thread), and then backed away from that.  It sure would be nice if 
someone really did implement erlang-style concurrency in a smalltalk 
varient.  (Flow of control always strikes me as the real shortcoming of 
smalltalk.)

Miles

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