Erlang style processes for Python

[Jacob Lee]

On Thu, 10 May 2007 00:19:11 -0700, Kay Schluehr wrote:
> [snip]
>> 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
> 

Interesting. Scala's pattern matching also looks nice. They have a
construct called a "case class" which is sort of like an algebraic data
type in that == compares the actual internal structure of the objects...
come to think of it, it reminds me of the proposal for named tuples that
floated around one of the python lists recently.

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

There are also a lot of places where Python implicitly shares data, though.
Global variables are one -- if you disallow those, then each actor has
to have its own copy of all imported modules. I think the GC is also not
at all threadsafe. I'm not familiar enough with how the interpreter works
to judge whether disallowing shared memory would make any of the existing
obstacles to removing the GIL easier to deal with.

Certainly, if it's doable, it would be a big win to tackle these problems.

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

Thanks!

-- 
Jacob Lee <artdent at freeshell.org>