At 11:18 AM 9/27/2005 -0600, Bruce Eckel wrote:

Yes, defining an class as "active" would: 1) Install a worker thread and concurrent queue in each object of that class. 2) Automatically turn method calls into tasks and enqueue them 3) Prevent any other interaction other than enqueued messages

#3 is the sticky bit. Enforcing such restrictions in Python is *hard*. Each active object would have to have its own sys.modules, for example, because modules and classes in Python are mutable and use dictionaries, and modifying them from two thread simultaneously would be fatal. For built-in types it's not so bad, so they could be shared... except for the fact that they have reference counts, which need lock protection as well to avoid fouling up GC. So really, this idea doesn't really help with GIL removal at all. What it *does* help with, is effective use of multiprocessor machines on platforms where fork() is available, if the API works across processes as well as threads.

So yes, the best way for this to work might be some kind of enforced implementation -- but forcing you to do something is not particularly Pythonic,

But keeping the interpreter from dumping core due to program bugs *is* Pythonic, which is why the GIL would need to stay. :)

so I would think that it would be possible to build an active object framework along with some checking tools to warn you if you are breaking the rules.

Well, you could pickle and unpickle the objects you send from one function to another, and for cross-process communication, you'll need to do something like that anyway, or else use that shared-memory objects thing. PySHM? I don't remember its name, but it's an extension that lets you store Python objects in shared memory and use them from multiple processes, modulo certain strict limitations.

But what's not clear is whether this would require knowledge of the innards of the Python interpreter (which I don't have) or if it could be built using libraries.

If you're not trying to get rid of the GIL or truly "enforce" things, you can do everything you need for CSP in plain old Python. peak.events has a generator-based microthread facility that's CSP-ish, for example, although it doesn't have decorators for async methods. They're not hard to write, though; Chandler has some for methods that get called across thread barriers now. That is, methods that get called from Chandler's UI thread but are run in the Twisted reactor thread. I've occasionally also thought about implementing async C#'s "chord" features in Python for peak.events, but I haven't actually had a use case that needed that much generality yet.

Bruce Eckel wrote:

Since the enqueuing process serializes all requests to active objects, and since each message-task runs to completion before the next one starts, the problem of threads interfering with each other is eliminated. Also, the enqueuing process will always happen, so even if the queue blocks it will be for a very short, deterministic time. So the theory is that Active Object systems cannot deadlock (although I believe they can livelock).

I've done this at work (in C++, not Python), and it works very well. I had my doubts when my boss first put the architecture for it in place, but a couple of years of working with this architecture (and that boss!) persuaded me otherwise. Livelock is a definite issue, particular if you design the individual active objects as finite state machines - it is fairly easy to get into a situation where Object A is waiting for a particular message from Object B, while Object B is waiting for a particular message from Object A. This chain is generally indirect, which makes it hard to spot. It is, however, still easier to figure this out than it is to figure out normal threading bugs, because you can find it just by analysing a sequence diagram showing message exchange and state transitions, rather than caring about the actual underlying code. Threading bugs, on the other hand, can turn up any time you access a shared data structure.

BTW: I think that Hoare's Communicating Sequential Processes (CSP) basically describes the idea of active objects but without objects. That is, I think active objects is CSP applied to OO.

Or to put it another way, applying OO to CSP is a matter of hiding the addressing and sending of messages behind method calls. It becomes almost like doing in-process remote procedure calls. I think there's a definite synergy with PEP 342 here as well - one of the problems with handling Active Objects is how to allow other messages to be processed while making a blocking call, without losing your current state. One way is to hold any state that persists between messages in the object itself, but that's a seriously unnatural style of programming (it can be done, it's just a pain). PEP 342's yield expressions can probably be used to help address that problem, though: class SomeAO(ActiveObject): def processSomeMessage(self): msg = yield # Do something with the message next_msg = yield makeSomeBlockingCall(self) # Do something with the next message Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

On 9/28/05, Greg Ewing wrote:

Nick Coghlan wrote:

...

PEP 342's yield expressions can probably be used to help address that problem, though:

class SomeAO(ActiveObject): def processSomeMessage(self): msg = yield # Do something with the message next_msg = yield makeSomeBlockingCall(self) # Do something with the next message

I don't see how that helps, since makeSomeBlockingCall() is evaluated (and therefore blocks) *before* the yield happens.

Sounds like makeSomeBlockingCall is just misnamed (probably depending who you ask). I wrote a small library recently that wraps Twisted's Deferreds and asynchronous Failure objects such that you can do stuff like try: x = yield remoteObject.getSomething() except Foo: print "Oh no!" This is just a 2.5-ification of defgen, which is at twisted.internet.defer.{deferredGenerator,waitForDeferred}. So anyway, if your actor messages always return Deferreds, then this works quite nicely. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | -- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// | -- http://twistedmatrix.com |o O| | w----v----w-+

Greg Ewing wrote:

Nick Coghlan wrote:

...

PEP 342's yield expressions can probably be used to help address that problem, though:

class SomeAO(ActiveObject): def processSomeMessage(self): msg = yield # Do something with the message next_msg = yield makeSomeBlockingCall(self) # Do something with the next message

I don't see how that helps, since makeSomeBlockingCall() is evaluated (and therefore blocks) *before* the yield happens.

Chris got it right - I just named the function badly. The idea is that there would be an interaction with the Active Object's event loop to get the actual result back once it was available from the thread that actually made the blocking call. In the meantime, *this* object could continue to handle other messages. What the approach allows is to have a single physical thread with a number of coroutiney-type event handlers running inside it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

I'd like to restart this discussion; I didn't mean to put forth active objects as "the" solution, only that it seems to be one of the better, more OO solutions that I've seen so far. What I'd really like to figure out is the "pythonic" solution for concurrency. Guido and I got as far as agreeing that it wasn't threads. Here are my own criteria for what such a solution would look like: 1) It works by default, so that novices can use it without falling into the deep well of threading. That is, a program that you write using threading is broken by default, and the tool you have to fix it is "inspection." I want something that allows me to say "this is a task. Go." and have it work without the python programmer having to study and understand several tomes on the subject. 2) Tasks can be automatically distributed among processors, so it solves the problems of (a) making python run faster (b) how to utilize multiprocessor systems. 3) Tasks are cheap enough that I can make thousands of them, to solve modeling problems (in which I also lump games). This is really a solution to a cerain type of program complexity -- if I can just assign a task to each logical modeling unit, it makes such a system much easier to program. 4) Tasks are "self-guarding," so they prevent other tasks from interfering with them. The only way tasks can communicate with each other is through some kind of formal mechanism (something queue-ish, I'd imagine). 5) Deadlock is prevented by default. I suspect livelock could still happen; I don't know if it's possible to eliminate that. 6) It's natural to make an object that is actor-ish. That is, this concurrency approach works intuitively with objects. 7) Complexity should be eliminated as much as possible. If it requires greater limitations on what you can do in exchange for a clear, simple, and safe programming model, that sounds pythonic to me. The way I see it, if we can't easily use tasks without getting into trouble, people won't use them. But if we have a model that allows people to (for example) make easy use of multiple processors, they will use that approach and the (possible) extra overhead that you pay for the simplicity will be absorbed by the extra CPUs. 8) It should not exclude the possibility of mobile tasks/active objects, ideally with something relatively straightforward such as Linda-style tuple spaces. One thing that occurs to me is that a number of items on this wish list may conflict with each other, which may require a different way of thinking about the problem. For example, it may require two approaches: for "ordinary" non-OO tasks, a functional programming approach ala Erlang, in combination with an actor approach for objects. Bruce Eckel http://www.BruceEckel.com mailto:BruceEckel-Python3234@mailblocks.com Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e" Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel

This paper looks very interesting and promises some good ideas. It also looks like it will require time and effort to digest. I've only read the first few pages, but one thing that does leap out is at the beginning of section 3, they say: "... a purely-declarative language is a perfect setting for transactional memory." What's not clear to me from this is whether STM will work in a non-declarative language like Python. Thursday, September 29, 2005, 8:12:23 AM, Michael Hudson wrote:

Bruce Eckel writes:

...

I'd like to restart this discussion; I didn't mean to put forth active objects as "the" solution, only that it seems to be one of the better, more OO solutions that I've seen so far.

What I'd really like to figure out is the "pythonic" solution for concurrency. Guido and I got as far as agreeing that it wasn't threads.

Here are my own criteria for what such a solution would look like:

Just because I've been mentioning it everywhere else since I read it, have you seen this paper:

http://research.microsoft.com/Users/simonpj/papers/stm/

? I don't know how applicable it would be to Python but it's well worth the time it takes to read.

Cheers, mwh

Bruce Eckel http://www.BruceEckel.com mailto:BruceEckel-Python3234@mailblocks.com Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e" Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel Subscribe to my newsletter: http://www.mindview.net/Newsletter My schedule can be found at: http://www.mindview.net/Calendar

At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:

This paper looks very interesting and promises some good ideas. It also looks like it will require time and effort to digest.

I've only read the first few pages, but one thing that does leap out is at the beginning of section 3, they say:

"... a purely-declarative language is a perfect setting for transactional memory."

What's not clear to me from this is whether STM will work in a non-declarative language like Python.

I spent a few weekends studying that paper earlier this year in order to see if anything could be stolen for Python; my general impression was "not easily" at the least. One notable feature of the presented concept was that when code would otherwise block, they *rolled it back* to the last nonblocking execution point. In a sense, they ran the code backwards, albeit by undoing its effects. They then suspend execution until there's a change to at least one of the variables read during the forward execution, to avoid repeated retries. It was a really fascinating idea, because it was basically a way to write nonblocking code without explicit yielding constructs. But, it depends utterly on having all changes to data being transactional, and on being able to guarantee it in order to prevent bugs that would be just as bad as the ones you get from threading. Oddly enough, this paper actually demonstrates a situation where having static type checking is in fact a solution to a non-trivial problem! It uses static type checking of monads to ensure that you can't touch untransacted things inside a transaction.

1) It works by default, so that novices can use it without falling into the deep well of threading. That is, a program that you write using threading is broken by default, and the tool you have to fix it is "inspection." I want something that allows me to say "this is a task. Go." and have it work without the python programmer having to study and understand several tomes on the subject.

Bruce, this seems to me like wishful thinking. Either the separate threads don't interact, in which case you are running separate programs, in which case os.system() already works well enough, or they do, in which case you have the various deadlock and livelock problems of threading. And this nonsense about threaded programs being "broken by default" -- might as well say the same about programs that use variables. If you don't know how to use threads, great, just don't use them. Spend the time reading Fred Brooks' NO SILVER BULLET, instead. It's available in essay form at http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html.

One thing that occurs to me is that a number of items on this wish list may conflict with each other, which may require a different way of thinking about the problem.

That seems correct to me. Bill

"Phillip J. Eby" writes:

At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:

...

This paper looks very interesting and promises some good ideas. It also looks like it will require time and effort to digest.

I've only read the first few pages, but one thing that does leap out is at the beginning of section 3, they say:

"... a purely-declarative language is a perfect setting for transactional memory."

What's not clear to me from this is whether STM will work in a non-declarative language like Python.

I spent a few weekends studying that paper earlier this year in order to see if anything could be stolen for Python; my general impression was "not easily" at the least. One notable feature of the presented concept was that when code would otherwise block, they *rolled it back* to the last nonblocking execution point. In a sense, they ran the code backwards, albeit by undoing its effects. They then suspend execution until there's a change to at least one of the variables read during the forward execution, to avoid repeated retries.

It was a really fascinating idea, because it was basically a way to write nonblocking code without explicit yielding constructs. But, it depends utterly on having all changes to data being transactional, and on being able to guarantee it in order to prevent bugs that would be just as bad as the ones you get from threading.

Oh yes, if implemented this really has be baked thoroughly into the implementation. It's not something that can be implemented as a library (as far as I can see, anyway).

Oddly enough, this paper actually demonstrates a situation where having static type checking is in fact a solution to a non-trivial problem! It uses static type checking of monads to ensure that you can't touch untransacted things inside a transaction.

Well, this is an extension of the way Haskell deals with side-effects in general... but yes, it's interesting to be sure. Cheers, mwh -- People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. -- Linus Torvalds

Bruce Eckel wrote:

I'd like to restart this discussion; I didn't mean to put forth active objects as "the" solution, only that it seems to be one of the better, more OO solutions that I've seen so far.

What I'd really like to figure out is the "pythonic" solution for concurrency. Guido and I got as far as agreeing that it wasn't threads.

I've pondered this problem. Python deals programmers a double whammy when it comes to threads: not only is threading unsafe like it is in other languages, but the GIL also prevents you from using multiple processors. Thus there's more pressure to improve concurrency in Python than there is elsewhere. I like to use fork(), but fork has its own set of surprises. In particular, in the programmer's view, forking creates a disassociated copy of every object except files. Also, there's no Pythonic way for the two processes to communicate once the child has started. It's tempting to create a library around fork() that solves the communication problem, but the copied objects are still a major source of bugs. Imagine what would happen if you forked a Zope process with an open ZODB. If both the parent and child change ZODB objects, ZODB is likely to corrupt itself, since the processes share file descriptors. Thus forking can just as dangerous as threading. Therefore, I think a better Python concurrency model would be a lot like the subprocess module, but designed for calling Python code. I can already think of several ways I would use such a module. Something like the following would solve problems I've encountered with threads, forking, and the subprocess module: import pyprocess proc = pyprocess.start('mypackage.mymodule', 'myfunc', arg1, arg2=5) while proc.running(): # do something else res = proc.result() This code doesn't specify whether the subprocess should continue to exist after the function completes (or throws an exception). I can think of two ways to deal with that: 1) Provide two APIs. The first API stops the subprocess upon function completion. The second API allows the parent to call other functions in the subprocess, but never more than one function at a time. 2) Always leave subprocesses running, but use a 'with' statement to guarantee the subprocess will be closed quickly. I prefer this option. I think my suggestion fits most of your objectives.

1) It works by default, so that novices can use it without falling into the deep well of threading. That is, a program that you write using threading is broken by default, and the tool you have to fix it is "inspection." I want something that allows me to say "this is a task. Go." and have it work without the python programmer having to study and understand several tomes on the subject.

Done, IMHO.

2) Tasks can be automatically distributed among processors, so it solves the problems of (a) making python run faster (b) how to utilize multiprocessor systems.

Done. The OS automatically maps subprocesses to other processors.

3) Tasks are cheap enough that I can make thousands of them, to solve modeling problems (in which I also lump games). This is really a solution to a cerain type of program complexity -- if I can just assign a task to each logical modeling unit, it makes such a system much easier to program.

Perhaps the suggested module should have a queue-oriented API. Usage would look like this: import pyprocess queue = pyprocess.ProcessQueue(max_processes=4) task = queue.put('mypackage.mymodule', 'myfunc', arg1, arg2=5) Then, you can create as many tasks as you like; parallelism will be limited to 4 concurrent tasks. A variation of ProcessQueue might manage the concurrency limit automatically.

4) Tasks are "self-guarding," so they prevent other tasks from interfering with them. The only way tasks can communicate with each other is through some kind of formal mechanism (something queue-ish, I'd imagine).

Done. Subprocesses have their own Python namespace. Subprocesses receive messages through function calls and send messages by returning from functions.

5) Deadlock is prevented by default. I suspect livelock could still happen; I don't know if it's possible to eliminate that.

No locking is done at all. (That makes me uneasy, though; have I just moved locking problems to the application developer?)

6) It's natural to make an object that is actor-ish. That is, this concurrency approach works intuitively with objects.

Anything pickleable is legal.

7) Complexity should be eliminated as much as possible. If it requires greater limitations on what you can do in exchange for a clear, simple, and safe programming model, that sounds pythonic to me. The way I see it, if we can't easily use tasks without getting into trouble, people won't use them. But if we have a model that allows people to (for example) make easy use of multiple processors, they will use that approach and the (possible) extra overhead that you pay for the simplicity will be absorbed by the extra CPUs.

I think the solution is very simple.

8) It should not exclude the possibility of mobile tasks/active objects, ideally with something relatively straightforward such as Linda-style tuple spaces.

The proposed module could serve as a guide for a very similar module that sends tasks to other machines. Shane

[ I don't post often, but hopefully the following is of interest in this discussion ] Bruce Eckel wrote:

Yes, defining an class as "active" would: 1) Install a worker thread and concurrent queue in each object of that class. 2) Automatically turn method calls into tasks and enqueue them 3) Prevent any other interaction other than enqueued messages

Here I think the point is an object that has some form of thread with enforced communications preventing (or limiting) shared data. This essentially describes the project we've been working on with Kamaelia. Kamaelia is divided into two halves: * A simple framework (Axon) for building components with the following characteristics: * Have a main() method which is a generator. * Have inbound and outbound named queues implemented using lists. (akin to stdin/out) * Access to an environmental system which is key/value lookup (similar purpose to the unix environment). (This could easily grow into a much more linda like system) * A collection of components which form a library. We also have a threaded component which uses a thread and queues rather than a generator & lists. With regard to the criteria you listed in a later post: 1) Has been tested against (so far) 2 novice programmers, who just picked up the framework and ran with in. (learnt python one week, axon the next, then implemented interesting things rapidly) 2) We don't deal with distribution (yet), but this is on the cards. Probably before EuroOSCON. (I want to have a program with two top level pygame windows) 3) We use python generators and have experimented initially with several tens of thousands of them, which works suprisingly well, even on an old 500Mhz machine. 4) Self guarding is difficult. However generators are pretty opaque, and getting at values inside their stack frame is beyond my python skills. 5) Deadlock can be forced in all scenarios, but you would actually have to work at it. In practice if we yield at all points or use the threaded components for everything then we'd simply livelock. 6) Regarding an actor. Our pygame sprite component actually is very, very actor like. This is to the extent we've considered implementing a script reading and director component for orchestrating them. (Time has prevented that though) 7) Since our target has been novices, this has come by default. 8) We don't do mobility of components/tasks as yet, however a colleague at work interested in mobility & agent software has proposed looking at that using Kamaelia for the coming year. We also ran the framework by people at the WoTUG (*) conference recently, and the general viewpoint came back that it's tractable from a formal analysis and mobility perspective(if we change x,y,z). (*) http://www.wotug.org/ I wrote a white paper based on my Python UK talk, which is here: * http://www.bbc.co.uk/rd/pubs/whp/whp11.shtml (BBC R&D white papers are aimed at imparting info in a such a way that it's useful and readable, unlike some white papers :) So far we have components for building things from network servers through to audio/video decoders and players, and presentation tools. (Using pygame and tkinter) Also we have a graphical editting tool for putting together systems and introspecting systems. An aim in terms of API was to enable novices to implement a microcosm version of the system. Specifically we tested this idea on a pre-university trainee who built a fairly highly parallel system which took video from an mpg file (simulating a PVR), and sent periodic snapshots to a mobile phone based client. He had minimal programming experience at the start, and implemented this over a 3 months period. We've since repeated that experience with a student who has had 2 years at university, but no prior concurrency, python or networks experience. In his 6 weeks with us he was able to do some interesting things. (Such as implement a system for joining multicast islands and sending content over a simple reliable multicast protocol). The tutorial we use to get people up to speed rapidly is here: * http://kamaelia.sourceforge.net/MiniAxon/ However that doesn't really cover the ideas of how to write components, use pipelines, graphlines and services. At the moment we're adding in the concept of a chassis into which you plug in existing components. The latest concept we're bouncing round is this: # (This was fleshed out in respect to a question by a novice on c.l.p - # periodically send the the same message to all connected clients) # start from Kamaelia.Chassis.ConnectedServer import SimpleServer from Kamaelia.Chassis.Splitter import splitter, publish, Subscriber class message_source(component): [ ... snippety ... ] def main(self): last = self.scheduler.time while 1: yield 1 if self.scheduler.time - last > 1: self.send(self.generateMessage, "outbox") last = self.scheduler.time splitter("client_fanout").activate() source = message_source().activate() publish("client_fanout", source) # perhaps something else? def client_protocol(): return Subscriber("client_fanout") SimpleServer(protocol=client_protocol, port=1400).run() # end

From the perspective of using multiple CPUs, currently we're thinking along the lines of this. I'lll use existing examples to make things more concrete.

Currently to build a player to decode and playback dirac [1] encoded video in python, we're doing this: [1] http://dirac.sf.net/ pipeline( ReadFileAdaptor(file, readmode="bitrate", bitrate = 300000*8/5), DiracDecoder(), RateLimit(framerate), VideoOverlay(), ).run() Sometimes, however, it would be nice to take a YUV file, encode, decode and view (since it simplifies the process of seeing changes): pipeline( ReadFileAdaptor(FILENAME, readmode="bitrate", bitrate= 1000000), RawYUVFramer( size=SIZE ), DiracEncoder(preset=DIRACPRESET, encParams=ENCPARAMS ), DiracDecoder(), VideoOverlay() ).run() Clearly on a multiple CPU machine, it would be useful to have the processing cross processes, so we're intending on using a process chassis (a chassis is a thing with holes or can have things attached) to run the components in a different python process. The likely syntax we'll be playing with would be: pipeline( ReadFileAdaptor(FILENAME, readmode="bitrate", bitrate= 1000000), RawYUVFramer( size=SIZE ), SubProcess( DiracEncoder(preset=DIRACPRESET, encParams=ENCPARAMS ), ), SubProcess( DiracDecoder()), VideoOverlay() ).run() This is intended to run over 3 processes. (One parent, two children) For the degenerate case: pipeline( SubProcess( ReadFileAdaptor(FILENAME, readmode="bitrate", bitrate= 1000000)), SubProcess( RawYUVFramer( size=SIZE ),) SubProcess( DiracEncoder(preset=DIRACPRESET, encParams=ENCPARAMS ), ), SubProcess( DiracDecoder()), SubProcess( VideoOverlay()) ).run() We're actively considering the possible sugar: DistributedProcessPipeline( ... original list of components ... ) But we're looking to walk before running there. Much like we implemented the underlying functionality before pipelines and that before implementing graphines. One issue you potentially raise in this scenario is how you find existing components that may exist without having tight coupling. The way we're working on this is to have named services which you look up in a linda-type way. One nasty thing we found there is that the code can start looking snarled up. That was until we realised because we have a scheduler that we can implementing almost-but-not-quite-greenlet style switching using generators. Specifically a pygame based component can do a lookup for an actve display thus: def main(self): yield WaitComplete( self.requestDisplay(DISPLAYREQUEST=True, callback = (self,"control"), size = (self.render_area.width, self.render_area.height), position = self.position ) ) display = self.display Where requestDisplay does this: def requestDisplay(self, **argd): displayservice = PygameDisplay.getDisplayService() self.link((self,"signal"), displayservice) self.send(argd, "signal") for _ in self.waitBox("control"): yield 1 display = self.recv("control") self.display = display That said, having seen your post further down the thread about a set of requirements you post, I think on many fronts we hit much of the aims you list. This is largely for one simple reason - our primary aim is that of making concurrency __easy__ to deal with, whilst not sacrificing the portable scalability. This is also why we've worked on graphical tools for putting together these pipelines, as well as looking inside. We have a deliberately naive C++ implementation based on the mini-axon tutorial which uses Duffs device to implement generators for example. I'd love to see that implementation expand since I think it'd generate a whole set of questions that need answering and would probably benefit the python implementation. Mind you hopefully pypy and shedskin will mitigate /our/ need to do that translation manually :-) If anyone's interested further, I'm happy to talk more (I'm going to Euro OSCON is anyone wants to discuss this there), but this feels like spamming the list so I'll leave things at that. However, so far we're finding the approach is a good one for our needs. The reason I'm posting about it here is because I think Kamaelia directly hits every point you made, but mainly in the hope it's of use to others (either directly or for cherry picking ideas). Best Regards, Michael. -- Michael Sparks, Senior R&D Engineer, Digital Media Group Michael.Sparks@rd.bbc.co.uk, http://kamaelia.sourceforge.net/ British Broadcasting Corporation, Research and Development Kingswood Warren, Surrey KT20 6NP This e-mail may contain personal views which are not the views of the BBC.

that stm paper isn't the end. there's a java implementation which seems to be exactly what we want: http://research.microsoft.com/~tharris/papers/2003-oopsla.pdf