Destructors in Factor
Saturday, September 8, 2007
After spending way too much time trying to perfect Factor’s win32 api
code, I wrote a word I should have written long ago: with-destructors
.
What this allows you to do is allocate a system resource, add a
destructor, and automate the resource cleanup, even when an exception is
thrown. Take this buggy code as an example of resource leaks.
TUPLE: mallocs one two three ;
: three-mallocs-buggy ( -- obj )
100 malloc
200 malloc
300 malloc
\ mallocs construct-boa ;
Any one of these calls to malloc could fail. If the first one fails, an error is thrown and no resources are lost. However, if the second or third fail, nothing will ever clean up after the successful allocations, and resources are leaked!
One alternative is to put each malloc into a tuple slot as they succeed. This solution is quite verbose and needs an extra cleanup word (boilerplate).
TUPLE: mallocs one two three ;
: cleanup-mallocs ( mallocs -- )
dup mallocs-one [ free ] when*
dup mallocs-two [ free ] when*
dup mallocs-three [ free ] when* ;
: three-mallocs-verbose ( -- obj )
\ mallocs construct-empty
f
[
drop
100 malloc over set-mallocs-one
200 malloc over set-mallocs-two
300 malloc over set-mallocs-three
t
] [
[ cleanup-mallocs ] unless
] cleanup ;
We need a boolean because we only want to cleanup up resources if something fails. See how we save each malloc as it’s created? Otherwise it could get lost. This tedious method is how much of the win32 native io (io completion ports) is implemented right now. Notice that the cleanup word doesn’t even set all the slots in the tuple to f, so if you called cleanup-mallocs twice somehow, your program would hopefully crash (sooner rather than later!). More boilerplate would fix it.
Instead, let’s wrap each returned resource in a destructor.
TUPLE: mallocs one two three ;
: three-mallocs ( -- obj )
[
100 malloc dup [ free ] f add-destructor
200 malloc dup [ free ] f add-destructor
300 malloc dup [ free ] f add-destructor
\ mallocs construct-boa
] with-destructors ;
Ah! This is marginally more work than the first example, but is 100%
correct. The word add-destructor ( obj quot always? -- )
takes an
arbitrary object, a destructor quotation (some code), and a boolean to
tell it under which circumstances to cleanup the resource. Calling
add-destructor
with t
will always clean up the resource; calling it
with f
will only clean up if the quotation passed to
with-destructors
fails. Thus, a cleanup routine is required elsewhere,
but we can worry about that later. The duplicated code could be factored
out if you find yourself using it often, but I have chosen not to here
because of the tricky boolean flag for add-destructor
. In practice, I
need to save about half of the resources and to destroy the other half
very soon after creation. However, it still might be best to factor out
the duplicate code:
: destruct-malloc-on-fail ( obj -- ) [ free ] f add-destructor ;
This example is trivial compared to using win32 for memory mapped io, which requires: escalating two privileges, opening a file, creating a file mapping, calling map view of file, and lowering both privileges, any of which could fail! This series of calls allocates two file handles and requires unmapping the file during cleanup. The four calls to the privileges routines call malloc, and this could also leak resources!
This complexity is the norm when writing code for performance and reliability in win32.
The destructor implementation is simple:
USING: continuations kernel namespaces sequences vectors ;
IN: destructors
SYMBOL: destructors
SYMBOL: errored?
TUPLE: destructor obj quot always? ;
<PRIVATE
: filter-destructors ( -- )
errored? get [
destructors [ [ destructor-always? ] subset ] change
] unless ;
: call-destructors ( -- )
destructors get [
dup destructor-obj swap destructor-quot call
] each ;
PRIVATE>
: add-destructor ( obj quot always? -- )
\ destructor construct-boa destructors [ ?push ] change ;
: with-destructors ( quot -- )
[
[ call ] [ errored? on ] recover
filter-destructors call-destructors
errored? get [ rethrow ] when
] with-scope ; inline
with-destructors
and add-destructor
make up the main interface. If
the quotation passed to with-destructors
succeeds, the
always-destructs are filtered out of the destructor sequence, and
call-destructors
destroys the objects that are left.
Hopefully this library will make dealing with system resources in Factor all but trivial.