This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Idle-ing when no one's interested Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

In this case, it turns out that if I could determine when I have 1 or more observers and when that changes, I could start and stop the process accordingly. So I set to do such a thing.

If you've done your own efficiently observed object, then you know that doing so is a matter of three things:

1. Add an ivar to your object (often called eventHandlers).
2. implement myEventTable which returns your new ivar.
3. implement myEventTable: which sets your new ivar as the argument .

Armed with such a knowledge, I figured I could just override myEventTable: and update my data gathering process state there. Thinking that myEventTable: was used anytime a change was made to the observable's observed state. Turns out that's not quite what you want though.

There's another method called setActionList:forEvent:. This appears to be the work horse of event table management, including removal. By implementing:

MyClass>>setActionList: aList forEvent: anEvent
	super setActionList: aList forEvent: anEvent
	self updateProcessState

i was able to automagically have the process run/stop based on whether anybody was listening. Seems to work pretty well so far, at least the following test seemed to pass:

testLoopManagement
	| block1 block2 |
	self deny: loop isPolling.
	block1 := [:arg | ].
	block2 := [:arg | ].
	loop
		when: #newStats
		send: #value:
		to: block1.
	self assert: loop isPolling.
	loop
		when: #newStats
		send: #value:
		to: block2.
	self assert: loop isPolling.
	loop removeAllActionsWithReceiver: block1.
	self assert: loop isPolling.
	loop removeAllActionsWithReceiver: block2.
	self deny: loop isPolling