[Stackless] Fwd: Is Stackless single core by nature?

OvermindDL1 overminddl1 at gmail.com
Sat Jul 11 00:43:55 CEST 2009


Freaking, forgot that the stackless list does not auto reply to the
list, it does not certain a certain header, why is that still not
fixed...


---------- Forwarded message ----------
From: OvermindDL1 <overminddl1 at gmail.com>
Date: Thu, Jul 9, 2009 at 7:02 PM
Subject: Re: [Stackless] Is Stackless single core by nature?


On Thu, Jul 9, 2009 at 9:20 AM, Henning
Diedrich<hd at authentic-internet.de> wrote:
> /* snip wonderful post */

You asked if the Erlang-style Actor model could be built on stackless,
I did exactly that a few years back (Stackless 2.4, I *might* still
have my code somewhere, I never used it, mostly just made it to see if
I could).

Instead of having a channel link or even a link to an actor you had
PID's, functionally identical to how Erlang's PID's are.  You can send
a message to a PID (call it like a function) and it took any/all
passed in values and sent them directly to the receiver actor if
local, or pickled it up and sent it to another actor that handled
network communication or shared memory or whatever, it was extensible
and sent to to a receiver of the same type on another process and
unpickled it and sent it to an actor on that local process.  Each
actor had a receive function that returned a message, the receive
function could accept an optional callable object (usually a lambda or
a function) that was matched to messages (ala Erlang pattern matching,
so you only got messages you were interested in at the time, and when
receive was called again all skipped/queued messages were retested as
well), if there was no incoming message then the receive function
blocks, when a message came in the message was tested to see if it was
to be accepted or not and acted accordingly.  The receive function
could also accept a timout value in seconds, which internally it
tested for a message to return, if one did not exist then it sends a
message (the local pid and the currenttime+timeout and an incrementing
value) to a local timeout handler actor (local as in, in the process,
for speed reasons) and the timeout actor sent a timeout message when
the time elapsed, the receive function if it receive a message that
was not a timeout then it sent a message to cancel to the timeout
actor, else if the message it gets is a timeout then it compares the
incrementing value to make sure it matches what it sent, if not then
it is an old message that did not get a cancel in time and it ignores
it, else it throws a timeout exception that the actor can handle.

Basically, using the API I created, an actor in my system on top of
Stackless would look like:

def testActorNumber(initialValue=0):
 """
   This actor acts like an integer, if the message is an integer
   then it is added to the value, if the message is just a PID,
   it returns the value to the PID, if the message is a string
   and the string matches "EXIT", then this actor shuts down.
 """
 value = initialValue

 while True:
   message = receive() # accepts all messages, no timeout

   if isinstance(message, int):
     value = value + int
   elif isinstance(message, PID):
     PID(value)
   elif message=="EXIT"
     return
   # elif the message is anything else, accept and ignore it so it
does not clog our queue

Then create it like:
numPid = CreateActor(testActorNumber, 0)


It was a functional enough API, however it was bog slow, hence why I
never used it, only took about an hour to make though, including
tests.  Currently I am creating my own compiled Actor language that is
of a syntax that I more prefer.




More information about the Stackless mailing list