Smalltalk: Extensions to the Base

Finished Yet?

June 7, 2004 20:37:26.663

Last week swamped me. Try try again, I guess. This week, I'm going to do samples of some of the more interesting (I think) extensions to the base system.

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

Comments

Holy Crap!

[George Paci] June 8, 2004 14:23:36.000

It's probably obvious to Smalltalkers, but I had to read the tests before I figured out what you're doing: you're adding a method to blocks !

As in, to the actual class. As in, now any block anywhere in your code can be told to finishIn/orElse.

That's pretty cool.

Re: [This TAG is Extra] Finished Yet?

[ Travis Griggs] June 8, 2004 15:27:23.000

Comment on [This TAG is Extra] Finished Yet? by Travis Griggs

Thanks George. I get going kind of verbose sometimes (ok, nearly always). With this one addition, you can take any of your code, wrap a block around it, give it a timeout, and provide an alternative block. Things like:

	[self myDatabaseQuery] finishIn: 10 orElse: [self killTheQuery; logIt; returnDefaultAnswer]

[Carl Gundel] June 10, 2004 18:33:21.931

Wicked! Try that in language xyz.

The other cool thing you can do is create objects that stand in for blocks. I do this in Liberty BASIC. It comes in handy sometimes when you want an object that can have state or which can contain metadata. Go nuts! :-)