As the next step forward, I now have multiprocess support for basic pipeline. Essentially I have the equivalent of "self.link" implemented for multiprocesses. Kinda like the Postman in the MiniAxon tutorial. It's a little messy right now, but works, and does NOT require any changes to existing Kamaelia components. It builds on LikeFile from last years summer of code efforts and pprocess. The core code currently looks like this:

# setup code snipped, and specifically ProcessWrapComponent snipped

from Kamaelia.UI.Pygame.Text import TextDisplayer, Textbox
# Start the pygame based input in one process
X = ProcessWrapComponent(Textbox(position=(20, 340),
                                 text_height=36,
                                 screen_width=900,
                                 screen_height=400,
                                 background_color=(130,0,70),
                                 text_color=(255,255,255)))

# Start the pygame based output in another
Y = ProcessWrapComponent( TextDisplayer(position=(20, 90),
                                        text_height=36,
                                        screen_width=400,
                                        screen_height=540,
                                        background_color=(130,0,70),
                                        text_color=(255,255,255)) )

exchange = pprocess.Exchange()
chan1 = X.activate()
chan2 = Y.activate()

exchange.add(chan1)
exchange.add(chan2)

while 1:
    for chan in exchange.ready(0):
        if chan == chan1:
            D = chan._receive()
            if D[1] == "outbox":
                chan2._send( (D[0], "inbox") )
    time.sleep(0.1)

Clearly most of this would be wrapped up for reuse. The nice thing of course about this, once wrapped for reuse, is that splitting a program across multiple boundaries for reuse will be pretty trivial and simple, and any kamaelia program that wants to do this will find it pretty trivial to implement. Now the nice thing about the example above is that it uses pygame. In pygame, because it builds on SDL, you can only have one window open in your process. Therefore to have 2 windows, you must be using multiple processes. Now as you can see above, the pygame components require no change, and yet this DOES result in multiple windows.

Screenshots:
In this screenshot you see the Textbox on the left and the TextDisplayer on the right. (Both were written as part of summer of code last summer incidentally). You'll see I got a bit excited, but you'll also see a piece of text before I press return.

This screenshot is after I press return:

Note that the data has passed seamlessly from one to the other, across process boundaries and probably CPU boundaries too since this is running on a multicore machine. Here's the ps output:

top - 00:11:41 up 11:51, 13 users,  load average: 1.09, 0.72, 0.66
Tasks: 149 total,   4 running, 145 sleeping,   0 stopped,   0 zombie
Cpu(s): 83.0%us, 16.5%sy,  0.0%ni,  0.3%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st
Mem:   2066996k total,  1605500k used,   461496k free,   243348k buffers
Swap:  1959920k total,        0k used,  1959920k free,   789804k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7727 zathras   25   0 53740  13m 6516 R   96  0.7   0:16.31 MultiPipeline.p
 7729 zathras   25   0 52616  12m 6444 R   93  0.6   0:15.83 MultiPipeline.p

OK, these components are decidedly hogging CPU as well, but as you can see they are both able to do so, and are running happily concurrently and in a not much more awkward way than normal. It's also only more awkward than normal due to the fact I haven't yet implemented the syntactic sugar required to make this work happy...

The multiprocess/core code for the brave is here in subversion.

The future's here. The future's multicore.