> The upshot is that pause() tells the scheduler "please don't call me again > unless there's a new message in an inbox OR a message is taken from an > outbox".
... OR if a child component terminates :-) > For threaded components it means the same thing. However, since a threaded > component can genuinely sleep, if it doesn't ever bother checking its > inboxes > for messages, it will sleep for ever. As a result, for threaded > components, > it adds an optional timeout argument to say "sleep for this long". Whilst > this was added for practicality reasons, it does mean that self.pause() > has a > different meaning for generator components from threaded ones. When a ThreadedComponent calls self.pause() to go to sleep, it will be woken by messages arriving at an inbox, or being taken from an outbox. See lines 483-504 and 541 in ThreadedComponent.py: http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/ThreadedComponent.py#483 http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/Axon/Axon/ThreadedComponent.py#541 The timeout feature is there, to my mind, because it provide a convenient way to provide basic timing facilities, very nearly for free (since the threading.Event() object it uses to pause has an optional timeout argument already built in) In my understanding, there is therefore no difference between self.pause() for generator based components and threaded components, except from the fact that the pause-ing will not happen in a generator based component until the next yield statement is reached. > Now there's two ways that self.pause(timeout=delay) could gain the same > meaning for generator components. One is to change the scheduler to become > time aware. The other is for it to wrap up a call to "PausingService" that > will awaken you after a minimum of delay has passed. > > Personally I prefer the latter, but this raises two issues: > * By changing the scheduler we change Axon/Kamaelia in a more > fundamental > way. Not necessarily the correct way. Certainly in a way that makes > it > harder to hack on and modify. > * The latter approach would mean that we're either using a component > *inside Axon* itself. This goes against Axon's spirit to an extent, > but > is the simpler, and probably more robust solution. > > I would also suggest that the return value of self.pause() be something > that > is yieldable. I like the idea of self.pause() returning something you have to yield - to my mind that sorts the potential confusion that can surround the way that the self.pause() doesn't take effect until the next yield statement. I agree that the latter approach feels simpler and possibly cleaner; but maybe at the expense of scope for performance optimisation (without later going back and working out how to change the scheduler). However, we don't seem to have that many applications where performance is that critical anyway. However, generalising a bit, what would be nice to add to the scheduler would be finer grained control over what can and cannot cause a component's generator to be woken from a paused state. For example, many components have no interest in being awoken when a message is taken from their outbox (because they do not support sending to size-limited destinations). If you could say something like (but not necessarily exactly like) this: yield self.pause(timeout=0.001) or this: yield self.pause(ignoreOutboxes=["outbox","signal"]) or this: yield self.pause(timeout=0.001, ignoreAllOutboxes=true) then, as a component writer, I'd find that a quite nice extra level of optimisation I could choose to incrementally add to my components. No idea how it should be implemented though. However I think I'm making the point that perhaps there's scope for a more general mechanism which *would* be appropriate to incorporate into the scheduler. My gut feeling is that whatever is returned by self.pause(...) would be some kind of object/function that the scheduler would call. This object/function contains the intelligence needed to enqueue some kind of timeout event, or to block/disable other sources of events. Matt -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
