(forwarding as per final line :)
---------- Forwarded Message ----------
Subject: Re: [kamaelia-list] Re: Bidirectional Json-Rpc Server
Date: Friday 13 November 2009
From: Jim Burnes <jvbur...@gmail.com>
To: Michael Sparks <spark...@gmail.com>
Very interesting discussion, Michael. When I first considered the concept
of stream / pipe polymorphism it really rattled my brains. Basically they
are objects that conform to the shape of their current component. It blew
my mind and took me a while to consider the impact. At the time I was
thinking about this I was designing a malware analysis pipeline modeled
after the human immune system and the conformable aspect had many
similarities to how immune system cells can morph depending on their current
function.
I've not had a chance for detailed comment, but two brief comments:
> * Yes, sending components through Axon/Kamaelia pipelines does already
> happen. (Indeed, we'll often send around ("inbox", component) pairs
> because that's defined as a service.
>
Heh. I hadn't even yet considered pipelining Axon's own core objects
(mailboxes, microprocesses etc). Quite a bit of potential there for danger
:-)
Python-Axon pipelines are fully polymorphic, and as you suspected,
> fun.
> It's possible that typed inboxes may be useful though, but that's a
> different discussion.
>
Sure. If nothing else they carry type-safety and certainly performance
improvements by avoiding the serialization issues, but you still have the
capability to go all string or whatever. The utility of doing this is
another question. When everything is a string you have more flexibility in
what you can read or connect to. Everything is trade offs.
>
> * If you pass in-active/passive objects - ie not components and not
> microprocesses - through the pipeline, because they don't have a local
> thread of control, this is generally thread safe.
>
Good. I had considered this and it's nice to know that someone has
considered it.
>
> After all, when you put an object in an outbox, you no longer own it,
> and if you take something from an inbox you own it.
Yes.
This ensures the idea of single reader/single writer for any single piece
> of data, which
> eliminates whole classes of concurrency bugs. (You don't necessarily
> make a system much simpler, but you at least you know one sort of bug
> doesn't exist, and one that's normally awkward to sort out/find :-)
>
Good point.
>
> BUT, if you put a component in the pipeline, you need to be careful.
>
>
No doubt playing with serious FM at that point.
> Specifically, this means a component is expecting a component on an
> inbox. In that case, your recipient component cannot know in advance
> whether the recipient is a generator-type component, threaded
> component,
> or similar. (eg a generator inside a threaded chassis, which has been
> proposed)
>
>
Bottom line really:
> * If possible send passive objects.
>
>
Certainly.
> * Finally, consider building something actor-like on top. Everyone who's
> built a mini-axon has actually built something actor-like, so this
> shouldn't be that bad, but there's no real direct support for ad-hoc
> actor like stuff as yet.
>
> Michael -- since I haven't used Actor I'm not sure what that implies.
>
> [Incidentally Jim, I suspect you may be aware of these issues, but I'm also
> aware that the thread is archived, and may be read in future :-) ]
>
> > I still think that you may need some sort of "bus" or "kernel" object for
> > mailbox creation, but that may be a orthogonal issue.
>
> That's the purpose behind adaptive comms components really - since they can
> all create mailboxes.
>
>
I'm thinking from a single-responsibility standpoint, keeping the mailbox
and process factories in the kernel clean up a lot of coupling issues.
> Interestingly, whilst we don't do this in Kamaelia/Axon, MASCOT's
> equivalents
> to out inboxes/outboxes can exist independently of what we call components.
> It may be that upgrading inboxes/outboxes to fully fledged things may have
> some benefits.
>
>
Yes. My mailboxes are independent, but because parts of their code (at
least mine) require them to know their parent component it's hard for them
to exist independently unless you use an abstract class for inboxes and then
use a concrete class of inbox that "belongs" to a component. Right now I
think I'll try to hide those implementation details and let the kernel worry
about ownership and parent/child issues. Part of the refactoring that I'm
trying to complete.
BTW: Here's an issue I've been trying to solve. It would be nice if a
called object would have intrinsic knowledge of the handle of the object
that called it. That way I wouldn't need to have an object embed "this"
into the called method. If it were a subclassed object I could probably set
that up in a super constructor, but...
> For example, if I could send you a box that I allow you to share, it would
> provide an interesting means of creating a thread pool. (At present the way
> to do that really would be to send a Queue.Queue through a pipeline, and
> allow the recipients to all read from it, but that's a different
> conversation :-)
>
>
I think a pool is a special case of what I call a work FIFO. The work FIFO
is a component of a certain type with an inbox for new work units and an
outbox that is different in that it can connect to multiple components and
deliver it's work units round-robin.
So, using true flow-oriented programming (ala Linda etc), you have a
generator that enqueues work units into a typed FIFO. Workers of the same
type can attach/rendezvous at the FIFO and pick up the next available work
unit, which they are given round-robin. In the case of a thread pool,
couldn't you just populate the thread pool with a set of threads and have
the thread users (or a dispatcher) wait for them round-robin at the output.
When the thread is finished or completes it could be sent right back to the
thread pool's inbox for recycling.
Anyway...good discussion.
Jim Burnes
(BTW: Feel free to send this to the mailing list. I missed that.)
-------------------------------------------------------
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
