[Gd-hackers] Gwydion Dylan on MacOS X

[Bruce Hoult]

On Nov 13, 2007 2:29 PM, Dustin Voss <d_j_v at mac.com> wrote:
> Good! When I ported the SQL library over to Gwydion Dylan, I had to
> pull finalization out and use explicit close methods.

Please be extremely extremely careful with finalization!!!

I am using a modified Boehm with finalization at work and almost every
time someone writes a finalizer we get at least one very hard to find
bug due to race conditions (usually many months later).

Pure finalization that merely calls close() on some OS thing is ok.
The problem comes about when what you actually want is clean up at the
end of the program, in which case finalization is merely a
finite-memory hack that (sometimes) does the cleanup early.  In this
case the finalizer has to also remove the object from some data
structure containing a (non scanned by the GC) list of things to be
cleaned up. Because the design in Boehm is to by default run
finalizers synchronously from inside the garbage collector, *any*
memory allocation call can (and will, one day) run finalizers.  If
you're not incredibly careful in maintaining your cleanup list then
this will eventually cause  corruption when finalizers are run
removing things from that list in the middle of other code adding
things to the list.

You can not solve this problem with locks.

Either the lock is held by another thread in which case the GC blocks
and any other thread that tries to allocate memory deadlocks with it.
Or else the lock is held by the same thread and either (in the case of
simple locks) deadlocks with itself, or (in the case or recursive
locks) marches right on in and corrupts the data structure.

The only safe way to run finalizers that touch global data structures
is asynchronously after the GC returns to its caller, in a thread that
initially holds no locks.

Boehm supports this via some defines (though it is not the default)
but as d2c does not currently support threads we can not yet use this
support in Boehm.