[PEAK] Re: PEAK design pointers
Phillip J. Eby
pje at telecommunity.com
Sun Mar 7 17:10:31 EST 2004
At 03:29 PM 3/7/04 +0000, Paul Moore wrote:
>Hmm, I've read the events module, and as far as I can see it's aimed
>at a cooperative multitasking model. That doesn't seem to fit my
>application structure at all.
Actually, it does, since it's just a higher-level view of Twisted-style
callbacks. However, for your specific application, if you are skilled with
Twisted already, and the tasks you want to achieve are relatively simple,
it may not be worth you learning the 'peak.events' model.
Most of my uses of 'peak.events' are for things that have complex
interactions and "temporal rules" like "if we get lots of requests, and we
have less than the maximum number of processes started, then start more
processes up to a goal level, but no more than one every N seconds. If any
processes die while we're trying to get to the goal level, keep starting
processes. If we reach the goal level, reset the goal level to the minimum
number of processes." That sort of logic is very straightforward to
express as events.Task objects, but very very hard to do correctly with
just plain callbacks.
If your top-level framework needs to do that kind of task management, you
will probably sooner or later want to look at peak.events in more detail.
More information about the PEAK