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
|