Michael, It would be interesting to consider two policies:
1) A transmitter / receiver policy where, if no one is listening the message simply goes to /dev/null 2) A work / generator policy similar to the tuplespace concept where the work request is generated and queued. As threads attach or become available to consume the work, the work units are doled out round-robin. In this model the generator can create a workload, disconnect or even terminate. The worker threads are free to pick up a work unit, complete it, disconnect, re-attach or terminate. The FIFO is simply where they rendezvous. The first is consistent with a bus or backplane topology. The second one is consistent with a distributed processing model. How they would be implemented is simply a matter of considering the design trade offs I guess. What think ye? Jim Burnes BTW: I'm getting closer to my axon D release. My last refactor is trying to come up with the proper integration of a backplane or kernel controller. Hopefully this will eliminate some wierdness with having to tell the mailboxes who their parent is etc. On Tue, Nov 10, 2009 at 8:59 AM, Michael Sparks <[email protected]> wrote: > > On Tuesday 10 November 2009 14:36:38 Jim Easterbrook wrote: > > Is it possible to subclass Backplane() in order to create a backplane > > that knows when a subscriber is added or removed? > > > > I have a CPU intensive process creating stuff that is published to a > > backplane, and I'd like to suspend processing when there aren't any > > subscribers, to minimise load on the system. My first thought was to > > subclass Backplane(), but I'm not getting anywhere with that. > > > > Is this a silly idea? Is there another way of doing it that I haven't > > discovered? > > It's not a silly thought - the backplane code was written incredibly > quickly, > and is really quite simple so changing it to support this would be useful. > > I'll have a brief ponder. (The way to do it would be to also change the > primary data inbox to a null sink so that it can throw away data no one is > listening to without reactivating) > > An overview of how the backplane works inside is described incidentally on > pages 49 - 52 of the kamaelia tutorial which can be downloaded from here: > * http://www.kamaelia.org/PragmaticConcurrency > > (Incidentally, if you'd like a paper version, I can send you a copy in the > the > internal mail :) > > > Michael. > -- > http://yeoldeclue.com/blog > http://twitter.com/kamaelian > http://www.kamaelia.org/Home > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~----------~----~----~----~------~----~------~--~---
