[MLton-user] Does GC always trigger MLtonFinalizable?

[Wesley W. Terpstra]

On Feb 17, 2007, at 12:47 AM, Matthew Fluet wrote:
>> So, my original question again: does a GC collect promise to run  
>> all finalizers for all unreferenced objects?
>
> Sort of.  The code promises to run the finalizers for all objects  
> that were determined to be unreferenced during the GC.  However, if  
> some additional objects become unreferenced as a consequence of  
> running the finalizers (say, because an object being finalized this  
> round is holding the last reference to another finalized object),  
> then their finalizers won't run until the next garbage collection.

So the GC sequence is "determine referenced set (includes all  
finalizers' data), mark-sweep, run finalizers"?

I assume this is because "determine referenced set (only include  
referenced finalizers' data), run finalizers, mark-sweep" could  
create new objects before the mark-sweep and/or add references to  
data held by the finalizer, thus breaking the mark-sweep?

This sounds like it means I can't depend on the queries being  
finalized on close.

Ugh. Even worse, the user does this:
1. open database
2. create some query
3. hooks a SQL function that uses the query (valid; SQLite is fully  
re-entrant)

Now the finalizer for the query will never be run b/c:
the hook refers to the query ->
the query is never finalized ->
the database cannot be closed ->
the hook is not released -> ...

Great.

So, I can't depend on finalizers for the database and queries. I also  
can't depend on finalizers for queries only and use a 'close only if  
unreferenced policy' for the database.
=> I need to provide an explicit close for the database
=> Either database close invalidates all query handles or queries  
must be manually closed

... if I go the 'close invalidates queries' route, I'll need to use  
MLton.Weak so my doubly-linked list doesn't keep a query alive.

Well, I'm glad I asked. Otherwise the interface would have been buggy.

Maybe explicit query close isn't so bad after all! ;-)