[PEAK] Re: Infinite loop in events.subscribe()

[John Landahl]

On Mon, Feb 02, 2004 at 09:33:28PM -0500, Phillip J. Eby wrote:
...
> So what do you want instead?  Probably you want to subscribe to the 
> condition's 'value' attribute instead, which fires only when the value 
> *changes*, not whenever the value is true.

I see.  I didn't realize this was the behavior of a Condition, or that
it had its own underlying Value object.

...
> So, I guess to make a long story short, if you think you need to 
> 'subscribe()', double check to make sure that a Thread isn't the 
> appropriate solution.  'subscribe()' has comparable overhead, but doesn't 
> have comparable features.

This use case was not a place where a thread would make (immediate)
sense.  A parent component has a property which is an aggregate of sorts
of a property in one or more child components (which I recently made
into Condition objects).  I wanted the parent to get a notification when
any child properties change so that it can update its aggregate
property.  I suppose I could make this into a thread with a 'while True'
loop, but that seems like it might be a counterintuitive implementation.

> Actually, in general, when in doubt, use more 'events.Thread' 
> objects.  They don't use *any* resources while they're waiting, except 
> memory for the actual thread object: about 52 bytes + ~360 per active 
> generator.  Often it's hard to shake the mental model that a thread is 
> something very very expensive and complicated and not to be used lightly, 
> but incredibly light is exactly what 'events.Thread' objects are.  Their 
> task switch overhead is only slightly more than the cost of issuing the 
> same callback that you'd do in a callback-based program.

Yes, I remember running David Mertz's demo some time ago which had
Python handle (IIRC) 100,000 simultaneous microthreads like it was
nothing.  Impressive, to say the least.