finalisation

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Jan 27 01:57:47 UTC 2004


"Andreas Raab" <andreas.raab at gmx.de> recommends against
putting resource creation inside an #ensure: block.

	You may have something that says:
	
	    [resource := <some resource creating expression>
	    "... more stuff ..."
	    ] ensure:[resource release "close, whatever"].
	
	If, for whatever reason, the "resource creating expression" fails to
	complete (raising an exception, just terminating whatever) there is no way
	by which you can release the resource in the above code simply because the
	"resource" variable hasn't been assigned yet. Meaning that it is basically
	useless to put the creation part inside the ensured block.

What if you do

	resource := nil.
	[resource := <some resource-creating expression>.
	 "... more stuff ..."
	] ensure: [resource ifNotNil: [resource release]]

instead?

	The only thing you gain by doing this is that you cover the
	microscopically small chance that the computation gets
	terminated right after assigning to the resource variable but
	before entering the ensured block.

"A microscopically small chance" is usually defined as "it has never
happened to me and I don't care if it happens to you."  Let me give an
anecdote with names removed:

    <large American company> sold <university in non-American therefore
    unimportant country> a mainframe, together with a number of
    <vaguely PDP-11-ish but not really> machines to act as terminal
    controllers.  <university &c> had serious problems; the <vaguely &c>
    machines had to be rebooted at least once a day, sometimes several
    times, to unwedge them.  <large American company> eventually traced
    this to a timing window in the OS kernal for the <vaguely &c> machines.
    Their decision: "nobody else tries to put this much load on their
    machines so we're not going to fix the bug, you will have to buy some
    more of our machines."  Oh yes, it was <large American company> who
    recommended that configuration in the first place.  I _think_ they
    eventually provided an extra <vaguely &c> machine free, but I'm not
    sure about that.

The lesson I learned from that is "microscopically unlikely bugs WILL
happen" (or to put it in Discworld terms, one in a million chances
come off nine times out of ten).

A similar anecdote:  a Prolog system I once maintained (NOT Quintus
Prolog) had a subtle timing window:  if you pressed the interrupt key
twice in quick succession you could trigger a bug that left some core
data structures (think database, think stdio) scrambled.  I did my best
to fix that bug, but the stdio problem needed source access which I didn't
have.

The 
	resource := nil.
	[resource := allocate....]
	ensure: [resource ifNotNil: [resource release]]

pattern can't do, and isn't intended to do, anything about errors in
the allocation code, but it DOES close a timing window which WILL give
rise to an observed failure some day.



More information about the Squeak-dev mailing list