> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to