This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Finished Yet? 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

One thing the Smalltalk base library doesn't have is a simple way to do timeouts for arbitrary operations. For today's blog, let's pretend we want one. Smalltalkers often brag about their uber-powerful full closure blocks; what they often leave out is that they're first class objects too, which means we can extend them (i.e. add behavior to them). Since Block's represent an arbitrary unit of work, they're the obvious implementor for an arbitrary timeout behavior. With some help from a friendly IRC channel for a good method name, we come up with the following:

finishIn: aSeconds orElse: anAlternativeBlock 
	| thisProcess alarmClock |
	thisProcess := Processor activeProcess.
	^
	[
	[alarmClock := Process forBlock: 
					[(Delay forSeconds: aSeconds) wait.
					thisProcess interruptWith: [Timeout raise]]
				priority: thisProcess priority   1.
	alarmClock resume.
	self value] 
			on: Timeout
			do: [:ex | ex returnWith: anAlternativeBlock value]] 
			ensure: [alarmClock terminate]

This is the end game version. It went through some iterations, but this is where it's at today. To me, there is some interesting things going on here. One is of course, the notion of adding behavior to BlockClosure. The interruptWith: is another. This method allows you to stop a process wherever its at, execute some code with it, and then let it continue on its merry way. But we're going a step farther, we're using the interruptWith: to throw an exception; in this case an exception called TImeout created explicitly for this use.

There were some tricky parts to getting this right. The first is that you can't use the forkAt: method. Said method forks the new process before returning it to be stored in the local variable. If the new process runs fast and at high priority, when we ensure alarmClock terminate, alarmClock will still be nil. So we have to do the create and store, before we resume it.

Another tricky part is that the on:do: needs to wrap the alarmClock creation as well as the block value, this in case our delay is so short, that it never gets to the value and the timeout isn't handled.

In reality, I wrote tests for all of this and did it somewhat iteratively. The first two were easy.

testFinishInOrElseFinishes
	| value stopped |
	value := 0.
	stopped := false.
	[
	[value := value   1.
	value < 10] whileTrue] finishIn: 0.25
		orElse: [stopped := true].
	(Delay forSeconds: 0.5) wait.
	self assert: value = 10.
	self deny: stopped

testFinishInOrElseReallyStops
	| value stopValue |
	value := 0.
	[[value := value   1] repeat] finishIn: 0.1 orElse: [stopValue := value].
	(Delay forSeconds: 0.5) wait.
	self assert: value > 0.
	self assert: value = stopValue

We used those tests initially, which drove the development of an earlier more primitive of , and then found it wasn't as robust as we wanted, so the following three tests were added:

testZeroFinishInOrElse
	| did didnt |
	did := false.
	didnt := false.
	[did := true] finishIn: 0 orElse: [didnt := true].
	self assert: didnt.
	self deny: did

testNegativeFinishInOrElse
	| did didnt |
	did := false.
	didnt := false.
	[did := true] finishIn: -0.01 orElse: [didnt := true].
	self assert: didnt.
	self deny: did

testFinishInOrElseCanPropagateError
	self should: [[] finishIn: 0 orElse: [ZeroDivide raise]] raise: ZeroDivide