Erlang style processes for Python

[Kay Schluehr]

On May 10, 8:31 am, Jacob Lee <artd... at freeshell.org> wrote:
> Funny enough, I'm working on a project right now that is designed for
> exactly that: PARLEY,http://osl.cs.uiuc.edu/parley. (An announcement
> should show up in clp-announce as soon as the moderators release it). My
> essential thesis is that syntactic sugar should not be necessary -- that a
> nice library would be sufficient.

Synsugar is helpfull when you want to control compiler actions. Of
course you can do this also by means of __special__ attributes  but I
guess this becomes clutter when you work with certain exposed sections
in the code.

> I do admit that Erlang's pattern
> matching would be nice, although you can get pretty far by using uniform
> message formats that can easily be dispatched on -- the tuple
>   (tag, sender, args, kwargs)
> in the case of PARLEY, which maps nicely to instance methods of a
> dispatcher class.

Yes, I do think so too. It is more interesting to think about what
might be qualify as a message. Destructuring it is not hard in anyway
and I do also have a few concerns with naive pattern matching:

http://www.fiber-space.de/EasyExtend/doc/gallery/gallery.html#4._Chainlets_and_the_switch-statement

> The questions of sharing among multiple physical processes is interesting.
> Implicit distribution of actors may not even be necessary if it is easy
> enough for two hosts to coordinate with each other. In terms of the
> general question of assigning actors to tasklets, threads, and processes,
> there are added complications in terms of the physical limitations of
> Python and Stackless Python:
>  - because of the GIL, actors in the same process do not gain the
>  advantag of true parallel computation
>  - all tasklet I/O has to be non-blocking
>  - tasklets are cooperative, while threads are preemptive
>  - communication across processes is slower, has to be serialized, etc.
>  - using both threads and tasklets in a single process is tricky

Actors don't need locking primitives since their data is locked by
virtue of the actors definition. That's also why I'm in favour for a
runtime / compiler based solution. Within the shiny world of actors
and actresses the GIL has no place. So a thread that runs actors only,
does not need to be blocked or block other threads - at least not for
data locking purposes. It is used much like an OS level process with
better sharing capabilities ( for mailbox addresses and messages ).
Those threads shall not take part of the access/release GIL game. They
might also not be triggered explicitely using the usual threading
API.

> PARLEY currently only works within a single process, though one can choose
> to use either tasklets or threads. My next goal is to figure out I/O, at
> which point I get to tackle the fun question of distribution.
>
> So far, I've not run into any cases where I've wanted to change the
> interpreter, though I'd be interested in hearing ideas in this direction
> (especially with PyPy as such a tantalizing platform!).
> --
> Jacob Lee <artd... at freeshell.org>

I guess you mean tantalizing in both of its meanings ;)

Good luck and inform us when you find interesting results.

Kay