jessenoller.com

Kamelia already has MP sup­port, but I am not sure about how it is imple­mented. Have you thought about using Kamelia/Axon as a base?

A base for what? An Actor model built on top of mul­ti­pro­cess­ing? The mul­ti­pro­cess­ing pack­age is in python 2.6, and ide­ally — I’d like some­thing built on top of *that*.

The only rea­son I am think­ing about doing an Actor/Monitor imple­men­ta­tion is as an exper­i­ment, I’m not sug­gest­ing it for python core.

To flesh out my half-formed thoughts:

1) Yes, I am talk­ing about a base for an Actor/Monitor imple­men­ta­tion.
2) My point, inaptly expressed, was that Kamelia has already proven that it can work over a mul­ti­process abstrac­tion — and Axon already looks a lot like an Actor imple­men­ta­tion. Accord­ingly, it might be inter­est­ing to use Axon/Kamelia to build an Actor imple­men­ta­tion on top of the now-to-be-widely-available mul­ti­pro­cess­ing pack­age. Mul­ti­pro­cess­ing would be the low­est level, Axon above it.

In one way, this makes sense: I’m explor­ing the Axon inter­nals to learn from it — how­ever, much like twisted: Kamaelia is a *frame­work* — I’m pri­mar­ily inter­ested in a sin­gle library ala Drama­tis, or par­ley (other actor impls) which is light­weight and shows a sim­ple stand­alone implementation.

Another imple­men­ta­tion which could be included in Kam. which is built on top of 2.6 would also be good — my even­tual goal is to work with peo­ple like Adam Olsen (http://code.google.com/p/python-safethread/) to get a pro­to­type for some­thing that may one day be included in python-core (in the mul­ti­pro­cess­ing pack­age itself)

Right now, it’s just a series of jum­bled thoughts in my head: I’m not exclud­ing any­thing, and I’m for learn­ing from any given implementation

Are you aware that a com­plete mini-axon using gen­er­a­tors is tiny and the rest is opti­mi­sa­tions and extra stuff that you find use­ful in real world sys­tems? By tiny, I mean this small:
* http://www.kamaelia.org/MiniAxonFull

A mini-axon using processes would be equally light­weight (shorter prob­a­bly) and pretty awesome.

Also, it’s easy to con­fuse the two halves of Kamaelia. If you think of Kamaelia as just an actor-type imple­men­ta­tion, then it’s actu­ally more an actor-like imple­men­ta­tion, with STM & an inter­nal SOA sys­tem of just over 2000 lines (which is how big Axon actu­ally is, exclud­ing com­ments & docs), with 80,000 lines of examples…

How­ever, per­son­ally I view it as a mech­a­nism for build­ing com­po­nents which hap­pen to be best used in a con­cur­rent fash­ion. ie rather than view­ing it as “a mech­a­nism for using con­cur­rency”, I view it as “OK, assume we have con­cur­rency, how can we use this to assist in build­ing and main­tain­ing sys­tems”. Axon also gives you the tools for tak­ing these con­cur­rent sys­tems, and inter­fac­ing between con­cur­rent sys­tems and stan­dard code. (http://www.kamaelia.org/AxonHandle)

As a result, I view Axon as a library which pro­vides you with the tools wrap­ping up idioms use­ful for build­ing col­lec­tions of com­po­nents which be a framework.

Any­way, potato/potato, tomato/tomato — if you like, you like, if you don’t, you don’t.

I’d love to replace our exist­ing process based stuff btw with a mul­ti­pro­cess­ing based ver­sion though. If I was going to go down this route, I’d fol­low our mini axon tuto­r­ial to do so, largely becauseit’s essen­tially the start­ing point I took with the mul­ti­process stuff recently and it worked out pretty well.

Beyond this basic stuff though, I’ve noted that peo­ple gen­er­ally start talk­ing about co-ordination lan­guages and build­ing up pat­tern repos­i­to­ries. The inter­est­ing inter­sec­tion between these two which you get if you call things com­po­nents rather than actors is it becomes nat­ural to cre­ate com­po­nents called a chas­sis. These chas­sis often instan­ti­ate directly in con­crete usable form con­cepts that you’d nor­mally refer to as a pat­tern — Pipeline, Graphline, Carousel, Back­plane, Seq, TPipe, etc.

On a ran­dom note, you may want to check out MASCOT “Mod­u­lar Approach to Soft­ware Con­struc­tion, Oper­a­tion and Test”. I heard about it late last year, and it appears to have the same sort of archi­tec­ture as Kamaelia. Inter­est­ingly (to me) it makes the same key deci­sion — when you send a mes­sage out­side your com­po­nent, you don’t know who is going to receive it. This then enables (and requires) a higher level sys­tem for con­nect­ing com­po­nents together. The upshot is highly reusable com­po­nents. This doesn’t entirely sur­prise me — my ethos came from recog­nis­ing that asyn­chro­nous hard­ware sys­tems & net­work sys­tems look strik­ingly sim­i­lar… (cf http://www.slideshare.net/kamaelian/sociable-so…)

Any­way, ref­er­ence for MASCOT: http://async.org.uk/Hugo.Simpson/ — skip down to the end of the page for this PDF: http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Man… I was really pleased to be pointed at MASCOT, largely because it showed a large num­ber of other domains where the same basic model has been used for well over 30 years… Just with non-existent expo­sure, and slightly dif­fer­ent metaphors. Though we, like it, also have mech­a­nisms for auto­mat­i­cally visu­al­is­ing sys­tems, with a 1:1 cor­re­spon­dence. Beyond that this also gives us a model that matches Edward Lee’s “The Prob­lem with threads” — we’d released run­ning code long before that paper was published :-)

Any­way, I’m glad that you’re look­ing at what we’ve done. If you use it, that’d be great, and I’ll hap­pily merge any­thing you’d like to have a life. (the only com­ment I’d make there is metaphors and acces­si­bil­ity count — this is surely the point of python? :-) If you don’t take what we use etc but it helps you solid­ify your thoughts to “No, I don’t want that, I want this”, then like­wise, I’m equally glad. If you do that, I’d love to know what you do try, since I like to merge best prac­tice con­cur­rency ideas into Axon :-)

I’d *REALLY* sug­gest look­ing at MASCOT though. Really made my Christ­mas last year when I was pointed at it.

We’re cur­rently hav­ing lots of fun using con­cur­rency, pri­mar­ily by allow­ing it to make our lives eas­ier, and for­get­table about :) It’d be nice to see some­thing sim­i­lar on top of mul­ti­pro­cess­ing (which we’ll do if you don’t, but it’d be great if you did — but I’d under­stand if your view was that you pre­fer a pure actor (sender knows receiver) model.

Here Michael — I made a reply:
http://jessenoller.com/2008/10/29/actors-concur…