Hi Michael, On 07/10/2009 12:15, Michael Sparks wrote: [snip detailed explanation of Axon internal workings]
Thanks for the explanation. It fills in a few details I hadn't worked out from looking into the Axon code. > > In essence, this means that in some circumstance data can be pushed into the > consumer thread faster via "control" than via "inbox". If the consumer thread > empties the inqueue, then it can then collect from control, and cause the > thread to exit "early". > > Now, what self.sync() is doing in this scenario essentially is actually > essentially adding in a delay. I think it's doing something more than that, as I explain below, but of course some delay is expected. We've got hundreds of messages in the 'outbox' queue we want to be delivered before the 'signal' message is. Ensuring this happens will appear to delay the signal. > The sync() method actually has nothing to do with /bin/sync in unix, and in > retrospect, that name is not perfect. What the sync() method actually does is > this: > * It sends a message over a private threadsafe queue - threadedtoaxon - > which says call this in your thread. ie it's one way for a thread to ask > another thread to call something. > * It also essentially asks the other end to do this synchronously. > * Crucially this blocks until the scheduler thread has a chance to grab the > object from the queue. This is done *after* the box deliveries are dealt > with. (Which is why a "blind" time.sleep() doesn't guarantee delivery, > which I'm guessing you tried) > > The primary usage for sync is inside linkage _creation_ as the docs inside > the > module describe. The useful (to me) aspect of sync() is that it blocks until the box deliveries are made. This means that all my queued 'outbox' messages are taken off the queue and put into the normal (wrapper) component outbox before sync() returns. (This might not happen if the recipient component had size limited inboxes, but I don't use that feature.) Using sync() like this gives me the same behaviour in threaded components as I see in normal components. Whether this behaviour is as deterministic as it seems is another matter. > It might be a good idea to allow a means to say "wait until outbox flushed" - > to give something similar to /bin/sync before exitting. This should be fairly > simple to implement cleanly. If this is interesting/useful, please let me > know. It'd give you another way to gain some determinism in your code! Yes, a "flush" method in threadedComponent would be useful, even if it just calls sync(). It would make it clear why I'm doing what I'm doing. > I'd prefer to actually implement "3" above, but I can't guarantee a timeframe > for that - I'd rather implement that as a mini-axon first, and then build > outwards. Yes, I can see the appeal of 3. If people want the elastic buffering of queues they could add a "queue" component to their pipeline. > Hoping this is useful, Very, thanks. -- Jim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
