On Wednesday 04 January 2006 20:13, John Goerzen wrote: > On 2006-01-04, Krasimir Angelov <[EMAIL PROTECTED]> wrote: > >> I use ForeignPtrs everywhere in HDBC to try to make sure that > >> nothing like this happens, and also that The Right Thing happens > >> if a database handle gets garbage collected without being > >> explicitly closed first. > > > > I prefer not to rely on ForeignPtrs. It isn't guaranteed that they > > will be run. Another problem is that the order in which finalizers > > are executed isn't specified. In this case the connection handle > > can be > > Well, yes and no. It would be impossible to garbage collect (and > thus finalize) any object for which references to it still exist. > Statement handles in HDBC maintain references to the database handle > pointers, either directly or indirectly, so I can't see how it is > possible for a database handle to be finalized before the statement > handle in this situation.
Hi John, I fear it /is/ possible. This is a very unfortunate situation and one I had quite some difficulties to understand, when Simon Marlow explained it to me. The problem is that finalization of the statement handle might be delayed indefinitely. The data dependencies between statement and connection handle only ensures that whenever the statement handle is alive, then too is the connection handle. But it does not say anything about what happens in which order after /both/ are dead (garbage). As soon as the connection handle to garbage, too, bothe handles can be finalized in /any/ order. As I pointed out before, this is a very bad thing, because it makes finalizers a whole lot less useful than they could be if an order between finalizations could be specified (directly or indirectly). The arguments against such a solution are mostly: (1) it is difficult to implement efficienty and (2) the programmer could accidentally cause finalizer deadlocks by specifying circular dependencies. Ben _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
